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W elcome! 


The ARRL/TAPR Digital Communications Conference is the premier gathering of 
Amateur Radio digital enthusiasts in the country, if not the world. This year we 
welcome everyone to Chicago for the 34th meeting since these annual conferences 
began. 


As anyone who has ever attended a Digital Communications Conference will tell you, 
these gatherings are excellent venues for innovative ideas and discussions. Within these 
proceedings, for example, you’ll find papers on topics ranging from HF receiver testing 
to ARDOP, the Amateur Radio Digital Open Protocol. M ost of these papers are 
appearing in public for the very first time. 


The ARRL thanks Tucson A mateur Packet Radio (TAPR) for all the hard work they do 
to make these conferences successful. Were it not for TAPR, itis possible that the 
conferences would not occur at all. 


Dave Sumner, K1ZZ 
ARRL Chief Executive Officer 
September 2015 
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QRPi - A Raspberry Pi QRP TX Shield Design 


Zoltan Déczi, HA7DCD 
Budapest, Hungary 
+36 70 316 81 56 


zoltan@rfsparkling.com 


Abstract 


"Be Smart, Not Strong" this should be the self explaining phrase of the QRP term in amateur radio. 
Low power operation is always more difficult than using hundreds or thousands of watts RF power. 
But the smile on your face after the first thousands miles long QSO, using portions of one watt is 
worth the challenge! QRP enthusiasts instead of spending time and money on increasing power 
capabilities of its station prefer a smarter way: to learn about new modulations and coding techniques 
and applying them in everyday HAM operation practice. 


Nowadays one of the most impressive QRP mode is Joe Taylor, K1JT's [8] WSPR [9] (pronounced 
"whisper"). WSPR stands for "Weak Signal Propagation Reporter". Programs written for WSPR mode 
designed for sending and receiving low-power transmissions to test propagation paths on the MF and 
HF and recently UHF bands. Users with internet access can watch results in real time at wsprnet.org 


The QRPi board (or shield as referred by the community today) is an inexpensive way turning a 
Raspberry Pi single-board computer into a QRP transmitter. 


Keywords: QRP, RPi, SDR, WSPR, open-source 


Introduction 


My QRPi shield is inspired by the WsprryPi [10] open source program, I've started to play with it as 
any other HAM operator, experimenting with the WSPR mode. At the beginning | followed the 
available articles [2] and DIY [10] guides about connecting a Low Pass Filter (LPF) to the RF output 
pin (GPIO 4) of the RPi computer. As an enthusiastic RF engineer and HAM operator | was instantly 
measuring the output signal with a signal analyzer and found a broadband noise from 0 Hz up to 
several harmonics [Fig 1] That was obvious that a LPF solves only the harmonic content attenuation 
and doesn't help against the broadband noise of the RF signal synthesized with the BCM2835’s 
"General Purpose GPIO Clocks". 
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Figure 1. - RF Output spectrum of RPi's GPIO4 pin without filtering 


At that point | made a research to find the possible inexpensive but efficient way to filter out the noise 
around the carrier. Lew Gordon's excellent article [3] led me to start my circuit simulations and to build 
my early prototypes based on his Band Pass Filter (BPF) advice. After successfully optimizing the 
BPF [Fig 3] values considering the parasitic parameters of the applied SMD inductors | saw a great 
improvement at the output spectrum [Fig 2]. 
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Figure 2. - RF Output spectrum of RPi's GP1O4 pin after BPF 
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Figure 3. - Frequency response of the 10m, 3 element BPF ona VNA 


At that stage of the design the harmonics filtered by the LPF, and the broadband noise filtered by the 
BPF were both acceptable. However there were still one thing missing: no buffer stage to protect the 
BCM2835 SoC's clock generator output stage. Hardware failure due to the unbuffered operation of the 
WsprryPi program was reported by a few HAM operators, possibly due to overload from nearly 
broadcast transmitter stations. If buffer amplifier was already needed it was a good idea to add some 
gain to the system. Eventually using a single FET amplifier stage [fig 7] 10 dB gain achieved, 
delivering +20 dBm output power at the end of the LPF [fig 4]. 
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Figure 4. - RF output spectrum of RPi's GPIO4 pin after BPF + PA + LPF 


For ESD and static discharge protection an ESD suppressor diode was added to the antenna terminal 
of the circuit. 


I've targeted the absolutely smallest and most compact form factor. I've seen several RPi HAM 
accessories which were too "bulky" in my point of view. Using large external PCBs with long cables 
attached to the RPi it's destroy the true value of the card sized computer: small, mobile and flexible. 


As | wanted to give an inexpensive QRP shield for the HAM and RPi community, mass production 
capability (SMD parts) and cheap component selection (eg. no SMA connector) was mandatory from 
the initial planning phase. 


Regarding compactness I've exploited the advantages of inside PCB milling, leaving a gap for the 
RPi's LCD ribbon cable connector. This way the QRPi shield has low profile while sitting on the RPi, 
not even the highest point of the card-sized computer. This hopefully enables the use of popular stock 
RPi plastic enclosures with the QRPi. 


Figure 6. - Close up of a QRPi prototype PCB 
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Figure 7. - Schematic of the QRPi shield 


Figure 8. - Device Under Test on the spectrum analyzer 


Figure 9. - QRPi on a Raspberry Pi computer 


QRPi WSPR field tests 


Laboratory measurements and fine tuning is one thing, another important factor is the real life 
operation and feedbacks from beta testers. Measurement and reports accumulated using WsprryPi 
and the QRPi shield since December 2014 till nowadays on daily basis using the latest prototype [fig 
9]. Without any sophisticated antenna, using only a simple outdoor random wire at 2m height 
1000...2000 km QSOs are typical on the 10 and 20m band with the +20dBm output power [fig 10-11]. 


Until the release of this paper the following digital modes and tools were tried and measured using 
QRPi: 


e WSPR TX [10] - laboratory and field tests 

e WSUT [11] - due to lack of resources not tested yet by the author of this paper, but seen 
feedbacks from HAM operators who use this with RPi 

e CW TX [12] - laboratory tests 

e SSTV TX [13] - laboratory tests 

e Signal Generator tool [14] - laboratory tests 
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Figure 10. - HA7DCD - LA9JO, 2400km  14.097185 MHz, WSPR 
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Figure 11. - Several European stations copying QRPi WSPR beacon, WSPR 


Possible further developments 


However the BPF filter does the job when filtering broadband noise coming from the BCM2835 SoC, 
there are still issues when amplifying the relatively wide band RF signal. From my measurements and 
investigations | realized that the FET amplifier starts to work as a mixer when the CW signal and the 
broadband noise filtered portion driven to its gate. The mixing product can observed at the spectrum 
analyzer screenshot [fig 12], ranging from 0 Hz to 10 MHz on the left side. I've successfully simulated 
the QRPi mixing product behavior using noise signal from a signal generator, or driving two sinus 
signal on the gate of the FET. 


Investigation with FET biasing trials doesn't showed solution for this. The spurious content is still at 
acceptable level [fig 4] however for upcoming revisions considering another PA structure with less 
mixing behavior might be a good idea. 


From software side a possible workaround should be to understand BCM2835's clock generators 
usage deeply. Fine tune it and decrease noise. 
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Figure 12. - FET amplifier acting as a mixer because of wide band noise 
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HA5KFU Schénherz Amateur Radio Club 


8 


Reference List 


1. QRP definition - https://en.wikipedia.org/wiki/QRP_ operation 
2. TUTORIAL: TRANSMITTER (PA) OUTPUT FILTERS by Paul Harden, NA5N 


http :/Awww.aoc.nrao.edu/~pharden/hobby/ Ipf_pa.pdf 

3. Band Pass Filters for HF Transceivers by Lew Gordon, K4VX 
http://www.arrl.org/files/file/T echnology/tis/info/pdf/880901 7.pdf 

4. Raspberry Pi website - https://www.raspberrypi.org 

5. Raspberry Pi Low Level Peripherals - http://elinux.org/RPi Low-level peripherals 

6. Raspberry Pi SoC, Broadcom BCM2835 - http://www. raspberry-projects.com/pi/pi- 
hardware/bcm2835 

7. BCM2835 datasheet - http://www.farnell.com/datasheets/1521578.pdf 


8. K1JT website - http://physics.princeton.edu/pulsar/K1JT/ 
9. Weak Signal Propagation Reporter Network - http://wsprnet.org 


Raspberry Pi transmitter programs working with QRPI TX shield: 


10. WSPR - https://github.com/JamesP6000/WsprryPi 
11. WSUT - http://hajos-kontrapunkte.blogspot.hu/2014/04/silent-whisper-jt9-on-cubie-truck.html 
12. CW - https://github.com/JamesP6000/PiCW 
13. SSTV - https://github.com/JennyList/LanguageSpy/tree/master/RaspberryPi/rf/sstv 
14. Signal Generator - 
https ://github.com/JennyList/LanquageSpy/tree/master/RaspberryPi/rf/freq_pi 
15. HA5KFU Radio Club - http://na5kfu.sch.bme.hu 
16. Hackerspace Budapest - http://hsbp.org/ 


VOA Radiogram: T ext and I mages via Shortwave Broadcasting 
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Abstract: The Internet has largely replaced shortwave radio for the broadcast of news and 
information across international boundaries. A growing number of countries, however, are 
blocking Internet content from abroad. As a possible workaround, digital text modes familiar to 
the amateur radio community can be used to broadcast news via existing shortwave transmitters 
and can be received on any shortwave radio, but software is required to decode the text. VOA 
Radiogram is a weekly V oice of America program experimenting with text and images through 
a shortwave broadcast transmitter 


K eywords: broadcasting, HF, shortwave, MFSK 


Introduction 


International broadcasting services such as the V oice of America and BBC World Service traditionally 
employed shortwave radio to transmit news and information across national boundaries. In recent 
years, international broadcast content has shifted to the Internet as more audiences have access to this 
new medium. The Internet enables not only audio, but also text, images, and video to be conveyed over 
long distances, and it provides the audience with more control over the choice of content, as well as an 
immediate means of feedback. 


Unlike shortwave radio, Internet content is usually brought into a country via landlines, and is routed 
through Internet providers in the “target” country. These factors provide a national government the 
opportunity to block Internet content it deems undesirable. Circumvention technologies, e.g. Psiphon 
and Tor, afford audiences in the target country some opportunity to overcome this interdiction, but an 
even larger industry (much of it based in the United States) help governments step up their counter- 
circumvention efforts. 


Internet content can be disrupted not only by dictators, but also by disasters, both natural and caused 
by humans. 


Digital modes via analog broadcast 


In the past decades, while pondering solutions to Internet interdiction, | also became active in the 
amateur radio digital modes. | was most impressed by the ability of the digital modes to transmit text 
successfully even in the worst reception conditions. This led me to wonder if the digital text modes 
from amateur radio could be used on a shortwave broadcast transmitter. 


Educated by my engineering colleagues at the International Broadcasting B ureau (parent agency of the 
V oice of America), | learned that this could be done, at least in theory. In fact, the modes could even 
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be transmitted in the AM mode of the |BB’s shortwave broadcast transmitters, and received on typical 
low-cost shortwave radios lacking single sideband capability. Early tests used amateur radio 
transceivers with a dummy load “antenna” to nearby shortwave radios. By the spring of 2012, brief 
transmissions via private shortwave broadcast stations in the United States resulted in successful 
decodes hundreds of kilometers from the transmitter. 


In M arch 2013, VOA Radiogram went on the air. This half-hour program is transmitted four times per 
weekend through a 50-year-old GE transmitter, operating at 80 kilowatts, at the Edward R. M urrow 
transmitting station near Greenville, North Carolina. Two of the transmissions are via a curtain antenna 
directed to Europe, and two are via a dipole to the Caribbean. The broadcasts are typically heard both 
in and outside their nominal target areas. 


2015-04-12 02.40z 


Figure1: MFSK32 data, about 500 Hz wide, 1500 Hz above and below the 
5745 kHz carrier, as received by VOA Radiogram listener Roger in Germany. 
An interfering signal is in the upper sideband.1 


M ost of the content on VOA radiogram consists of science news from the V oice of America website, 
voanews.com. Text from the website is pasted to the transmit pane of Fldigi, the well-known digital 
encoding/decoding software from authored by David Freese, W1HK J. Fldigi transforms the text to the 
tones which are inserted into a digital audio file for broadcast. M ost listeners use Fldigi to decode, but 
some decode with other software, such as M ultiPSK and DM 780. 


Thousands of reports have been received from shortwave listeners and radio amateurs throughout 
Europe and North A merica, as well as some in Latin America, and, beyond the nominal coverage area 
of the North Carolina transmitter, in Asia and the Pacific. Listeners use a variety of equipment to 
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receive VOA Radiogram, including amateur transceivers, shortwave portables, antique radios with 
shortwave bands, and SDR black boxes and dongles. Reception on inexpensive radios is 


Figure 2: Typical equipment needed to receive and decode VOA 
adiogram broadcasts is a portable shortwave radio and a 
notebook PC, with a patch cord feeding audio from the former to 
the latter. Appropriate software is also necessary. 
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new Gor ww 


Figure 3: MFSK32 centered on 1500 Hz decoded in Germany, March 1, 
2015, 0230-0300 UTC on 5745 kHz. 
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especially encouraged. A udio is typically fed to a computer using a patch cord, or through an interface 
such as SignaLink. “Acoustic coupling,” in which the built-in microphone of a laptop computer is 
placed near the radio’s speaker, is not uncommon. 


MFSK and challengers 


During the early weeks of VOA Radiogram, modes of similar speeds were transmitted to compare the 
number of errors. The MFSK modes performed well early on, so, in the manner of boxing, “champion” 
MFSK took on challengers one at a time. One week the 110 word per minute PSK R125 would be 
followed by the 120-wpm M FSK 32, and the 220-wpm PSK R250 would be followed by the 240-word 
M FSK 64. In the subsequent weeks, MFSK modes would be compared to similar mode speeds of MT- 
63, DominoEX, and THOR. Throughout this process, the MFSK exhibited fewer, and at least no more, 
errors than the competing mode. 


With MFSK established as the most promising mode, VOA News content was transmitted in different 
speeds of M FSK to determine which provide ideal performance in shortwave broadcast conditions. 
Based on hundreds of reports, it was determined that M FSK 32, at 120 wpm, provides the best 
combination of performance and speed in the conditions experienced by most VOA Radiogram 
listeners. 


The MFSK 16 mode is slower but can be useful in difficult reception conditions. For reliable 
transmissions paths, such as the typical distance between an |BB shortwave relay site and most VOA 
target countries, MFSK 64 will usually succeed and allows twice the content during the time period 
than does M FSK 32. General guidelines for the use of MFSK modes under different conditions are 
summarized in Table 1. 


Table 1: Guidelines for the use of MFSK modes in different shortwave reception conditions 
Mode Speed (WPM) Expected Conditions 
MFSK16 60 Poor 
MFSK32 120 Fair 
MFSK64 240 Good 
MFSK128 480 Excellent 


During the first year of VOA Radiogram, it was also discovered that text via analog transmitter 
provided more reliable reception than voice via analog transmitter, i.e. the original purpose of these 
transmitters. In reception conditions where voice content may be difficult to comprehend, text often 
provides a 100% decode. T ext via shortwave extends the useful range of a shortwave broadcast 
transmitter. 


Another advantage of text via analog radio is the opportunity for “unattended reception.” Text content 
can be received during the overnight hours and read after waking in the morning. Or the text can be 
receiving during the day, to be read when returning home from work. 


If the Fldigi software is configured for the UTF-8 character set, and the user’s operating supports the 
language, alphabets with diacritics and even non-Latin characters can be accommodated. V OA 
Radiogram has successful transmitted content in Russian, Chinese, Tibetan, and even the right-to-left 
Persian language. This is obviously a vital feature in international broadcasting. 
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HAYES Hrqay ss sys Hye oe eal Sead AMIR aA BRST IS 


Figure 4: Tibetan text decided by Merkouris in Greece, August 31, 2015, 1930-2000 UTC on 
15670 kHz, using Fldigi. 


Images via shortwave broadcast 


A bonus of the MFSK modeis its ability to transmit images. Images can add to the meaning of aVOA 
News story, or enhance its credibility. 


SSTV modes have been tested on VOA Radiogram. MFSK has proven more satisfactory in part 
because, unlike with SSTV, the size and shape of the image can be adjusted. In general, images are 
limited to 200x300 or 300x200 pixels so that their transmission does no occupy too much time. Images 
of the same size in M FSK 16, 32, 64, and 128 require the same amount of time to transmit, but 
resolution sharpens as the baud rate increases. The higher baud rates, however, also increase the 
chances for interference, usually exhibited as lines in the decoded image. As with text, M FSK 32 has 
shown itself to be the best compromise, in this case between resolution and resistance from 
interference. 


lia 


a 


Figure 5: Four modes of images as received by Frank in the Netherlands, 
August 2, 2015, 1930-2000 UTC, on 15670 kHz. 


Images are often fuzzy or noisy, the more important text content is usually received 100% thanks to the 
error correction built in to the MFSK modes. 
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Images in EasyPal, which uses DRM (Digital Radio Mondiale) encoding, have also been tested on 
VOA Radiogram. This is the all-radio version of EasyPal, not the hybrid version that refers the user to 
a server for download. As is typical of digital communication, the results were either perfect (and 
dazzling) or completely absent. As impressive as the successes were, the failures were too frequent to 
encourage continuation of the Easypal experiments. The seven-minute transmission time for the most 
robust version of EasyPal images was another impediment. 


Figure 6: This EasyPal (DRM) image was decoded by Lorenzo 
in Italy, June 22, 2015, during the 1600-1630 UTC broadcast 
on 17860 kHz. 


J amming 


If a regime blocks Internet content from other countries, there is a good chance it will also jam 
shortwave broadcasts from abroad. China vigorously jams shortwave broadcasts from the U nited 
States and other Western countries. Usually this is done by placing Chinese domestic radio 
programming, usually from more than one transmitting site, on the same frequency as aV OA or Radio 
Free Asia broadcast in M andarin, Cantonese, Tibetan, or Uighur. Chinese operatic music or just noise 
is also used. 


To determine if the text modes via analog shortwave broadcast can penetrate jamming, brief text 
transmissions were inserted in the shortwave broadcasts of the VOA Mandarin and RFA Cantonese 
services. The transmitters were the usual IBB relay facilities in Asia. MFSK 16 and Olivia modes were 
used during these tests. M onitoring on receivers in Hong K ong and J apan demonstrated that these 
modes often, but not always, resulted in successful decodes of the Chinese text, despite conditions that 
prevented the comprehension of the accompanying VOA and RFA voice content. 
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Figure 7: Chinese text in MFSK16, centered on 2000 Hz, penetrated 
Chinese jamming, August 7, 2014, 2258 UTC on 9845 kHz, as received 
and decoded by TW in Japan. 


Similar successful tests were conducted with Radio M arti shortwave broadcasts, which are heavily 
jammed by Cuba. 


A future for text via shortwave broadcast? 


The Fldigi software has remarkable capabilities, but it may be intimidating to non-technical users. 
Furthermore, audiences for international broadcasting do not need the encoding capabilities of this 
software. Wider accessibility to text and images via analog shortwave broadcast will require the 
development of software applications to simplify the decoding process and to enable decoding to be 
possible on mobile devices. (An Android version of Fldigi, AndFlmsg, is already available in beta 
version.) 


It would also be very helpful for some shortwave receivers to include the ability to decode text modes. 
Such a development would be assisted by the adoption of one or asmall number of modes to be used 
in shortwave broadcasting, and encouraged by the transmission of text by more shortwave 
broadcasters. (T ext and images via analog radio can also be employed on the AM [medium wave] and 
FM radio bands.) 


The development of easier-to-use software and hardware will probably not transform text via 
shortwave into a popular mass medium. If this technology can reach a few thousand users in a country 
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or area cut off from external Internet traffic, those users can then relay the information through what 
would become the country’s intranet, or through non-electronic means in a disaster zone. 


The future of shortwave broadcasting, voice or text, is certainly in question. As audiences have 
migrated to television and the Internet, many major shortwave broadcast transmitting facilities have 
been dismantled. M ost developing countries have eliminated or largely curtailed their use of shortwave 
for domestic broadcasting now that their territories are covered by networks of FM and television 
transmitters. Fewer shortwave radios are available for sale; Sony, for example, is down to one model. 


There is some interest in adopting DRM (Digital Radio M ondiale) to increase the fidelity of shortwave 
broadcasts. DRM is, however, less forgiving than analogue shortwave, with the audio dropping out 
completely in reception conditions, e.g. diminished signal strength and co-channel interference, that 
are not unusual on the shortwave bands. In similar difficult conditions, text via shortwave is more 
forgiving than analogue voice via shortwave. The availability of this technology to work around 
Internet interdiction may not be available if analogue shortwave transmitters and receivers are no 
longer available. 


For more information about VOA Radiogram, including the transmission schedule, visit 
voaradiogram.net. 


The author acknowledges the assistance of Gerhard Straub, K6XH, Director, Broadcast 
Technologies in the office of Technology, Services, and Innovation of the U.S. International 
Broadcasting Bureau, and Daniel Maxwell, N5LAY, IBB TSI electronic engineer, in the 
development of the VOA Radiogram project. And Macon Dail, WB4PMQ, as well as the staff at 
the IBB's Edward R. Murrow shortwave transmitting station near Greenville, North Carolina. 
Additional education and encouragement were provided by my amateur radio friends 
Christopher Rumbaugh, K6FIB, and Benn Kobb, AK4AV. 


Figure 8: This $25 radio in Germany provided audio for 
a successful decode of VOA Radiogram text. 
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Images received from VOA Radiogram, program 51, 22-23 March 2014 
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MFSK32 images received 15-16 March 2014 
UTC: 0930 Sat 5745 kHz. 1600 Sat 17860 kHz. 
0230 Sun 5745 kHz. 1930 Sun 1570 kHz. 
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HF Receiver Testing: 


Issues & Advances 


(also presented at APDXC 2014, Osaka, Japan, November 2014) 


Adam Farson VA7OJ/AB40J 


Copyright © 2014 North Shore Amateur Radio Club 
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HF Receiver Performance Specs 
- what HF operators “shop” for 


Sensitivity 

- Test signal level for a given signal/noise ratio in a given bandwidth 

- Usually stated as Minimum Discernible Signal (MDS) or noise floor: 
° Input in dBm at 500 Hz bandwidth to raise audio output level by 3 dB 

Selectivity & shape factor 

- IF or detection bandwidth at -6 and -60 dB points on passband curve 

Reciprocal mixing dynamic range (RMDR) 

- Test signal level at a given offset from RX freq. to raise audio output by 3 dB, minus MDS 
° A function of local-oscillator phase noise 

2-signal, 3'¢-order IMD dynamic range (DR3) 


- Input power of each of two equal test signals at a given spacing and 500 Hz bandwidth to raise 
demodulated IMD product by 3 dB, minus MDS 


Blocking gain compression 


- Level of strong signal at a given offset from weak signal to reduce level of demodulated weak signal 
by 1 dB. RX tuned to weak signal; 500 Hz bandwidth. 
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More HF Receiver Specs 
- also important in choosing a rig 


2-signal, 2"4-order IMD dynamic range (DR2) 


- Input power of each of two equal test signals falling outside band under test at 500 Hz 
bandwidth to raise demodulated IMD product in band under test by 3 dB, minus MDS. 
Receiver tuned to band under test (typically 14 MHz). 


° Determines receiver’s susceptibility to QRM from HF broadcasters 
Frequency stability 


- Drift measured in Hz or parts per million (ppm) over time, and over a temperature range if a 
variable-temperature test chamber is available 


Not usually an issue with modern synthesized radios 


Inband IMD 


- Relative amplitude of either of two narrow-spaced test signals (typically spaced 200 Hz) and 
their associated IMD products, measured at audio output 


¢ Severe inband IMD causes listener fatigue 


Image & IF Rejection 
-  Anold problem returns in receivers with inband 15 IF 
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Main HF Receiver Impairments 


Intermodulation Distortion (IMD) 

- Odd-order IMD 

- Even-order IMD 

- IMD from multiple carriers approaches noise 

Reciprocal Mixing Noise 

- RF signal or noise mixes with LO phase noise 

Image Response, IF Leakage 

- RF signal or noise response at image freq. & IF 

Sensitivity/MDS is not an issue in modern receivers. 

- Below 21 MHz, the receiver noise floor is = 10 dB below band noise. 
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IMD: 


intermodulation distortion 


Odd-order IMD 
- IMD products usually in same band as received signals f,, f, 
-  3'-order IMD products: 2f, - f,, 2 f, - f, 
¢ Example: f, = 7010 kHz, f, = 7015 kHz. Products: 7005, 7020 kHz 
Even-order IMD 
- IMD products not in same band as f,, f,. 
-  24-order IMD product: f, + f, 
¢ Example: f, = 8025 kHz, f, = 6010 kHz. Product: 14035 kHz 
On a crowded band, multiple carriers generate a large number 
of IMD products 


- Limiting case is where spectrum of IMD products approaches Gaussian 
noise 
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IMD Example 


IMD Example: f, = 270 MHz, f, = 275 MHz. 
IMD products at 265 and 280 MHz. 
280 MHz IMD product masks weak signal. 
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Reciprocal Mixing Noise 


iF wth transated intertorer 


Desired 
Signal 


Weak Sjgnal_// 


-e 7. 


Crnanevel FREQUENCY Cnanneal 
Width Width 


Strong interferer mixes with LO phase noise to “throw” noise into IF channel. If the interferer consists 
of wideband noise, the IF channel will be filled up with noise. 
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Image Response, IF Leakage 


¢ Image response: 
- Acceptance of signals at fy + 2 * IF (f, = signal freq.) 
¢ Example: f)= 10455 kHz, IF= 455 kHz. Image: 10000 or 10910 kHz. 


—- In modern receivers with high 1° IF, RF 
preselector suppresses image response almost 
completely. 

e IF leakage: 


- Acceptance of signals at or close to 1° IF. 


¢ Example: 15t IF = 9 MHz. On 30m band, preselector may be sufficiently wide 
to pass some energy at 9 MHz. This will enter the IF chain and interfere with 
desired signals. 
- This is not a problem in receivers whose 1* IF is above the highest 
operating frequency. 
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Blocking and overload 


Blocking: degradation of receiver sensitivity in the presence of a 
much stronger (blocking) signal. 


Blocking gain compression occurs when the interferer drives the first 
active RF stage to its compression point, thus causing desensing. 


Blocking gain compression is the difference in dB between the level 
of an incoming signal which will cause 1 dB of gain compression, and 
the level of the noise floor. 


Note that in a direct-sampling SDR receiver, no blocking occurs until 
the ADC is driven into saturation (clipping). 
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Typical Superhet Receiver 
showing impairment areas 


Simplified block diagram of superhet receiver 
AGC 


Noten: 1, Inductor cores and some capacitors can 
generate passive IMD when driven into 


saturation IMD CHOKE POINTS 


2. Crystal litters génorate prasaive IMD PHASE NOISE SOURCE 


When excited inte Honlinear region, 


Multiple signals or wideband noise applied to RF IN will provoke IMD products at IMD choke points, 
and mix with LO phase noise to cause reciprocal mixing noise. 

= Steering diodes in RF/IF signal paths can also generate IMD. 
Passive IMD can occur in RF BPF components and crystal or mechanical filters. 


In addition to IMD and phase noise, image responses and IF leakage can arise if RF BPF is too wide to 
attenuate undesired signals at image frequency and IF. 


All these products will appear in IF/AF chain as added noise, spurs etc. 
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Issues in standard receiver test methods: 
instrument limitations 


Synthesized RF signal generators used for MDS, reciprocal mixing, blocking 
and IMD testing can have moderate to severe phase noise. This will degrade 
measurement accuracy. 


- Asolution: ultra-low-noise crystal oscillators. These are costly and not frequency- 


agile. A vacuum-tube LC-type generator is also usable, but has poor frequency 
stability/accuracy. 


Synthesized generators with excellent phase-noise performance are available, but 
are somewhat costly. 


Spectrum analyzers are frequently used for phase noise measurements. 
- Many high-end analyzer models support phase noise measurement software. 


- The limitation here is that the lowest phase noise value the instrument can display 
is that of its own internal phase noise. 
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Sig Gen Phase Noise Example 
HP 8640B & Marconi 2018A 


18 dB7 
RL ~4e dBo/Hz 
MI 
|| 


PN, -17 dBm, Red: HP B6SEB, Gheun? Mapcdni 2@18A ¥ 1184887815. 24.12.2016 
1] | 


FREQUENCY OFFSET 
16.86 CARRIER 
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Ultra-Low-Noise Crystal Oscillator 


TYPICAL SPECS: 


Level 

+13 dBm 22d8m into 50 ohms 
STABILITY 
Aging 

1x10 perday 

after 30 days operating, typical 


Tomporature Stability 
25x10" .0° to +60°C (Ref +25"0) 
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Typical 2-Tone IMD Test Setup: 
also used for blocking tests (see p. 17) 


30 JB GAIN 15 MHz 


HP 339A 
MARCONI 2018A 


MARCONI 2019 


14102kHz = 30. dB GAIN 15 Mrz 


BLOCK DIAGRAM OF TYPICAL TWO-TONE RECEIVER TEST SETUP 


Test signal power is adjusted for 3 dB increase in level meter reading. DR3 = test 
signal power — MDS. 


Amplifiers A1, A2 buffer the signal generators G1 and G2 to block RF sneak paths 
across the combiner. This prevents mixing in the generators’ output stages (a 
cause of IMD). 
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Improved RMDR Test Method 


using notch filter to improve accuracy 


MARCONI 20184 9830 kHz 0-110 dB RCVR HP 339A 


yi 

LEVEL 
(1 ) | NOTCH FILTER { var ATT anal DUT is tedee 
—— 


BLOCK DIAGRAM OF RECIPROCAL MIXING TEST SETUP 


Notch filter (notch at fy, depth > 80 dB) between sig. gen. and DUT. 
f, = freq. of max. attenuation. Af = offset. 


DUT tuned to fp. Sig. gen. tuned to f, + Af; input power to raise audio output 
by 3 dB is noted. 


Notch filter suppresses sig. gen. phase noise at f,, thus improving 
measurement accuracy. 


RMDR = input power — filter passband insertion loss — MDS. 
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Issues in 2-tone 3'¢-order IMD dynamic range (DR3) testing: 
subtractive test method 


ARRL uses subtractive DR3 test method (ITU-R SM.1837 Sec.2). 


- IMD product amplitude is measured at audio output using signal analyzer with 1Hz or 3Hz 
RBW, to subtract out the noise contribution. 


The DR3 value obtained via this method is meaningless unless RMDR is measured and the 
result presented alongside DR3. 


- ARRLare now presenting RMDR alongside DR3 in their QST Product Reviews. 


A “100 dB” radio with 85 dB RMDR is not a 100 dB radio; it is an 85 dB radio! 
To claim otherwise is deceptive advertising. 


If RMDR < DR3, reciprocal mixing noise will mask that “weak one” long before 
IMD product does. 


In a practical on-air operating environment, artifacts and splatter from distant 
transmitters will mask weak signals much more often than will IMD in the 
local receiver. 


This is more an operational and regulatory problem than a technical one. 
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Issues in 2-tone 3'¢-order IMD dynamic range (DR3) testing: 
classical test method 


In the DR3 test method outlined on p. 14, the IMD + noise amplitude is 
measured at the audio output using an RMS level meter such as the HP 3400 
or 339A. 


The test engineer must measure RMDR and DR3. If RMDR > DR3, the test 
result is DR3. If RMDR < DR3, we are reading RMDR. 


To check, turn off f, and f, in turn. If audio output drops by less than 3 dB 
when either f, or f, is switched off, the test result is RMDR, not DR3. 


This is acceptable; the test will reveal whether IMD or reciprocal mixing is the 
receiver’s dominant impairment. 


In on-air operating, reciprocal mixing (RM) can arise more often than IMD, as 
only one undesired signal will produce RM whereas two are required for IMD 
to occur. 
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Masking of weak signal 
when reciprocal mixing exceeds IMD 


=> = == = RM Noise 


IMD Example: f, = 270 MHz, f, = 275 MHz. 
IMD products at 265 and 280 MHz. 
Reciprocal mixing noise masks weak signal. 
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Issues in SDR testing: 


direct-sampling SDR characterization 


With the advent of fast, cost-effective ADCs, the direct-sampling SDR has 
eclipsed its QSD (quadrature-mixer) predecessors. 


This architecture poses new challenges to the test engineer: 
DR3 and RMDR have no relevance as performance metrics. 


- DR3 increases with increasing test-signal power, reaches a peak at ~ -10 dBFS (10 dB below 
ADC clipping) and then drops rapidly. 
IP3 (3-order intercept) is meaningless here, as IMD in an ADC follows a 
quasi-15t-order rather than a 3-order law. 


- The transfer and IMD curves diverge, and never intersect. In a conventional receiver, IP3 is the 
convergence point of the transfer and IMD curves. 


As the ADC clock is the only significant phase-noise source, a very-low-noise 
crystal clock oscillator almost eliminates reciprocal mixing noise. 


- RMDRis so high (>> 100 dB) that even the very best crystal oscillators as test signal sources 
can degrade the measurement. 
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Pout [dB] 
40 4 


The IP3 Problem in an ADC 


Legacy receiver 3 [dBm P28) Direct-sampling SDR (FS (dBmy 
_ 40 40+ 
+30 


-20 : 0 +20 0 
Fn [dB] Pin (AFI 


IM3 product increases 3 dB per dB of input power IM3 product is nearly independent of input power 


(0 dBFS = ADC clipping level) 
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The effect of dither on IMD 
Try this with your old rig! 


Measurement of IM3 - Product with and without Dithering 
IM3 [dBm] 


-80 = 


-90 


—-wio Lith. 
—o—with Dith. 


Dither breaks up IMD 
products into noise 
which degrades RX 

, hoise floor by = 3 dB. 


Input Power [dBm] 
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The DR3 Problem: 


Perseus SDR vs. legacy receiver 


3rd-order Dynamic Range (OR3) dB 


Perseus & Legacy Receiver: 2-Tone DR3, 14.1 MHz, B = 500 Hz, 2 kHz spacing. VA70) Mar. 2014 
Perseus: preselector off, preamp on. Legacy: ATT =12d8 


‘SO 45 40 35 30 25 
2-Tone Input Power dBmitone 
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The DR3 Problem: 


discussion 


The chart (see previous page) shows that the DR3 of a direct-sampling 
receiver is unusable as a predictor of dynamic performance. 
DR3 increases with increasing input power, reaching a “sweet spot” at = -10 
dBFS, then falling off rapidly as O dBFS (ADC clip level) is approached. 

- Bycontrast, DR3 of the legacy receiver decreases with increasing input power. 
A new method for specifying receiver IMD is proposed: measure the absolute 
power of interferers (IMD products and spurs) against 2-tone input power, 
with the ITU-R P.372 band noise levels for typical urban and rural sites at the 
frequency of operation as datum lines. We term this IFSS (interference-free 
signal strength). 


- Ifthe interferer is below the band noise at the user site, the band noise will mask it 
and it will not be heard. 


The IFSS method allows comparison of SDR and legacy receivers. 
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IFSS IMD Power Measurement 
in SDR’s and legacy receivers 


We measure the absolute amplitude of each interferer (IMD product or spur) 
and draw a chart of interferer amplitude vs. per-tone test signal power at a 
500 Hz detection or IF bandwidth. 


- The ITU-R P.372-2 band noise levels for typical rural and urban sites (see next page) are shown 
as datum lines (-103 and -109 dB at 14 MHz, respectively.) 


If the interferer is below the band noise, it can be disregarded. 


The IFSS method eliminates the "sweet spot" problem in DR3 measurements 
on SDR's, and is valid for SDR and conventional receivers. 


The legacy receiver will often need front-end attenuation to bring its MDS 
into line with that of the SDR, which is = 10 dB worse as a rule.) 


The IFSS test method allows us to compare the IMD vs. input power 
performance curves of a direct-sampling SDR and a legacy receiver ona 
common chart as shown on p. 26. 
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ITU-R band noise levels 
(Courtesy ARRL) 


Residential — = Rural - Typical Receiver MOS 


Power (dBm) 


Frequency (MHz) 


Typical noise levels versus frequency for various environments. 
(Man-made noise in a 500-Hz bandwidth, from Rec. ITU-R P.372.7, Radio Noise) 
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IMD vs. input power (IFSS): 


Direct-sampling SDR vs. legacy receiver 


For the Perseus. 
Perseus SOR & Legacy RX, Two-Tone IMD. VA70)J, Jan.2014. 


the IMD curve is f, = 14100 kHz, f, = 14102 kHz. 500 Hz detection bandwidth. 
= 1St-order until ATT=12.dB on legacy RX. 

-25 dBm input 
level, then rises 
rapidly to 3'4- 
order due to IMD 
in active stages 
ahead of ADC. 


— Legacy RX IMD 
—— 508 IMD No Dither 
——s0R IMD Dither 
— — Urban Noise Floor 
— — Rural Noise Floor 


— — Legacy Noise Floor 


IMD Amplitude, d8min 500Hz bandwidth 


40 30 
Two Tone Input Power (per tone) indBm 
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Measuring dynamic range is easy 
but how do we measure absolute interferer levels? 


On a direct-sampling SDR, we can read the observed IMD product and 
interferer levels directly off the S-meter or spectrum scope. 
- The scope and S-meter level calibration should be checked before taking these 
readings. 
- A preamp ahead of the ADC will degrade IMD. 
On a legacy receiver, the procedure is more complex. 
- Read recovered audio level of IMD product or interferer on level meter. 


- Next, apply a single-tone test signal to the DUT RF input and adjust input power to 
obtain same level-meter reading. (AGC must be on.) 


IMD product/interferer levels can also be read off a legacy receiver’s 
calibrated signal-strength meter. 
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Other considerations for HF receiver testing 


The measurement of second-order IMD dynamic range (DR2) is still 
useful in SDR testing, as 2nd-order mixes in active stages ahead of the 
ADC can cause HF BCI. 

- Example: 41m BCI on the 40m amateur band in Region 1. 
Image rejection and IF leakage measurements are not applicable to 
direct-sampling SDR’s. 
The noise-power ratio (NPR) test is a useful tool for identifying 
impairments in SDR and conventional receivers. 


- Ifacomplete NPR test set (noise generator and noise receiver) is 
available, it can be used also for testing 2-port networks (amplifiers, 
filters etc.) 


http://www.nsarc.ca/hf/npr.pdf 
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References for further study 


http://www.itu.int/rec/R-REC-P.372/en 
http://tinyurl.com/testproc2011 (ARRL Test Procedure Manual, 2011) 


http://www.nsarc.ca/hf/npr.pdf 


http://www.ab4oj.com/test/docs/npr_test.pdf 
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AMATEUR RADIO EMERGENCY DATA NETWORK AT THE CENTER OF EMERGENCY COMMUNICATIONS PREPAREDNESS 


Andre Hansen, K6AH 

The AREDN Project (AREDN.org) 
2113 Via M onserate 

Fallbrook, CA 92028 
K6AH@ARRL.net 


A bstract 


M esh technology has been around for over ten years. Over the past two years developers on the 
AREDN™ team have advanced the art by porting Broadband-H amnet’s extremely popular mesh 
firmware to the Ubiquiti airM AX line of commercial Wireless ISP routers. This has literally changed 
the complexion of mesh implementations from an experimental, hobby-oriented, novelty into a viable 
alternative network suitable for restoring some degree of Inter/intra-net connectivity “when all else 
fails.” 


M ore recently, the developers of this software have kicked-off a new project, AREDN, focused on 
taking this technology to the next level in EMCOMM communications. 


This paper begins with an introduction to the AREDN Project and mesh networking and concludes 
with aroadmap for the Project’s future. It dives into implementation techniques and considerations as 
well as avoidable pitfalls. 


K eywords: AREDN, EMCOMM, mesh, BBHN 


Introduction 


The typical Emcomm message-passing scenario today involves the sender conveying the message to a 
ham, who transcribes it onto an |CS-213 form. Then the message is spoken over VHF/UHF radio to 
another ham who writes it down on another ICS-213 form. The form is then delivered to the recipient, 
who reads it and signs it. The acknowledgement is then conveyed back over the radio to the sending 
ham who confirms the receipt to the originator. 


Emcomm “Customer” expectations aren’t being met 


Customer expectations differ wildly than this. They expect the continued use of tools with which they 
are accustomed: email, phone service, chat, and other web-based tools specific to their roles within the 
organization. 
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Over $4B in ham-compatible radios is sold to non-hams each year and most hams wouldn’t recognize 
them to be ham radios. These devices follow the 802.11 standard and operate in several of our 
microwave bands. They are all around us, and coupled with the privileges our license offers, we 
should be using this technology to deliver on these customer expectations. 


So what is AREDN? 


AREDN is an RF network mesh of radio/routers operating under the FCC rules, Part 97 in the ham 
microwave bands, controlled by hams with a Tech license or higher. It is a high-speed data network 
with rates of up to 54 M bps designed to provide a TCP/IP medium when other network infrastructure 
has failed. While technically capable, it is not intended to be a general Internet access alternative. 


AREDN is written for Linux-based WIFI and WISP devices by the AREDN Development T eam which 
also authored the BBHN (Broadband-H amnet) releases from v1.0.1 to 3.0.1. 


AREDN replaces the manufacturer’s operating system with the following major components: 


1. OpenWRT, an OpenSource wireless routing framework onto which custom applications can be 
built 

2. OLSR (Optimized Link State Routing Protocol), an!P routing protocol optimized for dynamic 
ad hoc networks 

3. Web-based GU! for node configuration 

4. Automatic device-specific TCP/IP network configuration based on the device MAC address 


The primary objectives of the project are to empower the typical ham to become a deployable part of 
the network by simply installing the firmware, entering the station’s call-sign and an administrative 
password, and then pointing the node’s antenna toward an existing network node. 


The secondary objectives are to provide a means to monitor & manage the network and to specify a set 
of operational standards & services for Emcomm’s utilization of the technology. 


To date this technology has attracted 3 very different user types: 


1. Look at the cool things you can do! They’re intrigued by the autonomous nature of the network 
and quickly setup neighborhood networks for gaming, VoIP, etc. They tend to attract other 
computer types who may be enticed into Ham Radio as a result. 

2. Applying it toward a need. These guys weren’t looking for it, but see the value in it and apply 
it toward a specific need, such as Field-Day logging, race support, surveillance cameras, etc. 

3. Those who have longed for it... To these guys, the technology is game-changing. They arein 
the process of exploiting it by building infrastructure around it. 


This last type include the Emcomm guys. They are the primary target of this technology and the focus 
of the AREDN™ Project. 
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How it works 


It is easier to understand this technology if we start with how standard WIFI works. 


External Domain 
(Internet 


In the diagram above, we see two distinct “domains.” The User domain includes both wired and 
wireless devices. These are all in the same address space and nothing distinguishes them aside from 
how they connect to the WIFI router. 


The second domain is for the Internet. Y ou will note a firewall protects the User domain from 
unauthorized access and other threats from the external domain. 


How AREDN “repurposes” the device 


7 weer! wie. ~ 
| ee o\) i 


MESH P 


JR RE Domain yw 


i a ’ \ . * : 
” External WAN” X- ' ra, of: f 
/ Domain \ \ ; ; f 

| Sine ht 2 bs oe 


37 


W hat were two domains in our Standard WIF! diagram have now become three. We see the familiar 
external and user domains... although the user domain now contains a WIFI router and new computers 
which, in this case, deliver services such as email, FTP, VoIP, chat, etc. 


The new domain here is an RF mesh network which forms the business end of the AREDN 
technology. 


The Hardware 


I'll use this term “mesh” to describe the interconnection of devices, and “nodes” to describe the 
devices. Nodes are typically comprised of a Linux computer, a software-defined radio operating 
within a predefined microwave band, and a strip-line amplifier. Some utilize an on-board transverter 
as a means of reusing an existing device in another band. The computer has at least one Ethernet port, 
although some have two with an internal hub or switch. All of these components are contained within 
the single node. The radios contain either internal antenna or one or two antenna ports. These radio 
receivers are hot... with sensitivities in the range of -95dBm. Power output is in the range of 23 to 28 
dB m (200 to 600 mW). 


Historically, Ham Radio mesh networks have been built on Linksys W RT 54 devices intended for 
home and office use. These lower-powered (19dBm, 79mW ) units have required environmental 
protection when used outside, and as a result have been difficult to utilize in meshes extending beyond 
the neighborhood. Over the past 2 years AREDN developers have extended existing mesh technology 
to environmentally robust, commercially available, U biquiti, hardware. The devices supported are 
currently manufactured by U biquiti under their product group “airMAX” and the TP-LINK “Pharos” 
series. Support of these devices has literally changed the complexion of mesh implementations from 
an experimental, hobby-oriented, novelty into a viable alternative network suitable for restoring some 
level of Inter/intra-net connectivity when “all else fails.” 


The ARDEN software supports these devices on the 900 M Hz, 2.4 GHz, 3.4 GHz and 5.8 GHz 
Amateur Radio bands. 


a —_ 


_— 


SS 


b, ee GS Se 
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How OLSR Works 


Optimized Link State Routing determines the best path for data transmission through the network. 


Link Quality 80% 
Path Cost 1.25 


_———— 


j \ \ 
Mesh Domain / Lee \ 
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bya ? Go”. ”" Z j | / 
eT ees wr ‘ 
° O 
> — ya Ke 
“st we CF . 
cy 
= Mow 


The four devices illustrated above, all Ubiquiti N anoStations, have formed a “mesh.” The route data 
will take through this network is dependent on the quality of the links between them. Note the link 


between NodeA and NodeB. From historical broadcast reception, Node A knows that 80% of the 
data from Node B is received without error. In addition, Node B knows from historical reception, that 
data from Node A is received without error 100% of the time... itis said to be 80% reliable based on 
the following formula, where LQ =Link Quality and PL =% Packet Loss 


EQ: (PE BL 


A-B BA 


LQ = 8x1 
LQ = 80% 


Based on this, it assigns a “cost” (or ETX, estimated transmission) to the AB link inversely 
proportional to the Link Quality: 


Cost (aka ETX) =1/LQ =1/.8 =$1.25 
A-B 


All traffic from A to B will take this path, because it is the least expensive route available. To 
determine the path through multiple nodes, the individual link costs are simply summed. 


If the link between A and B where to fail, then NodeA would quickly calculate an alternate path. Two 
are available: 


Path A-C-B at acost of $1.00 + $2.10=$3.10 
Path A-C-D-B at acost of $1.00 + $1.00 +$1.00= $3.00 
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Node A’s routing table is updated with the new optimal path of A-C-D-B. These updates are 
performed multiple times each second, with routing table propagations through the mesh taking some 
amount of additional time depending on the size of the mesh. 


W hat the GU! does 


The Graphical User Interface is generated using HTTP by the AREDN software running on the 
embedded Linux computer. The GUI provides access to a variety of administrative and operational 
functions, such as: 


e Checking for traffic / congestion on the channel 
e Reporting the current node status and other nodes both directly or indirectly connected 
e The basic node configuration settings 
e More advanced administrative setting for 
o Port Forwarding / DHCP / Advertised Services 
o Network Address Translations for complex network environments 
o Updating the AREDN firmware 
o Installing useful service packages on the node 
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How Do! Build an AREDN Network? 
Building an AREDN network is not difficult: 


1. Weencourage one to have a specific objective before you begin. That may be simply to 
understand the technology, but such an objective should not creep into a production 
implementation without restarting with that new objective. 

2. Thenext step is to plan and deploy core nodes onto which mesh is formed. These nodes form 
an initial, primary path for network traffic. Note that they may or may not retain that 
distinction as the mesh grows. 

3. Setup purposeful services that align with your objective and user requirements. 

4, Utilize the mesh routinely to ensure it is operational and will be so with needed. 


Supported D evice Details 
Ubiquiti airM AX M -series wireless routers share the following general characteristics: 


e They are tower mountable and environmentally robust: 
o Temperature: -40° to +176°F, 
o Humidity: 5 - 95% Condensing 
e Many utilize a combination of horizontal and vertically polarized antenna to minimize 
unwanted interference from on-channel or adjacent WIFI noise. When conditions allow, they 
also support the combining of these polarizations for increased data throughput— called MIMO 
(M ulti-In, M ulti-Out). 


H ere are a few representative devices and characteristic selection criteria: 


e Rocket- A two RF portMIMO node (500mW) that is “plug and play” with a variety of 
U biquiti antenna systems: 90° and 120° Sector antenna, Dual-polarization Verticals, and 30- 
34dBi Dish antenna. Note that MIMO nodes split the power between the vertical and 
horizontal domains. 

e Bullet- A single RF port high-power (600mW ), non-M IMO node with an N-Type female 
connector suitable for direct connection to many 3 party antennas. With the right antenna this 
could easily achieve ranges of 50+ km. 

e NanoStation - A fully contained node with an internal 11dBi patch antenna and a 45° coverage 
pattern. 

e airGrid- A larger node available in several size/gain grid-reflector antenna configurations. 
Designed to be a highly directive, it performs at a range of from 10 to 30 km 


All of these devices obtain their operating power delivered over the CAT5 cabling (PoE or Power over 
Ethernet). They have a broad DC input voltage specification to accommodate a wide range of cable 
lengths which may be required for tower applications: 10.5 to 24V DC at the CAT5 connector. 
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In planning to deploy the core nodes it is advisable to use propagation prediction software such as 
Radio M obile to avoid the hassle and expense of experimentation. | will diverge for a bit for the 
benefit of those unfamiliar with this type or software. 


Radio M obileis a free propagation simulation system. It utilizes data from the Space Shuttle R adar 
Terrain M apping Mission (SRTM ) resulting in elevation contours which have then been overlaid with 
satellite imaging and road maps. It further utilizes the L ongley-Rice radio propagation prediction 
method, which computes the attenuation of radio signals using an “irregular terrain model”... a 
technique that has been successfully used in commercial radio coverage planning since the 1960's. 


Itis available both as a software download and a Web-based tool. While the download results in a 
more flexible tool, its installation is not for the faint-of-heart. | would advise that, if you do not 
consider yourself a computer expert, then the W eb-based tool will more than adequately meet your 
needs. The English language portal is at: htto://www.cplus.org/rmw/english1.htm! 


Sufficient use of this tool to explore the variables of band, node-model receiver sensitivity, and node- 
model power output, will result in the required antenna gain in either point-to-point (PtP) or point-to- 
multi-point (PtM P) topologies. 


Here are a screenshot from a typical Radio M obile analysis: 


(i, Radio Mobile Par/By Roger Coudé VE2DBE Information @ 


3.00 nV 5823km?2 302137 pop 949uV 3702km? 230766 pop 


ea 


Gh 


Description v | ¥ Sleeping Indian 16dB ¥' Nash William's Place 
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In my planning for a mesh in northern San Diego County, | secured a location in the Bonsall area. The 
marker locates the potential node(s) under review... in this case a pair of 2.4 GHz Ubiquiti Rocket 
nodes with 120° sector antenna, one pointed in the general southwest direction and other to the 
northeast. Based on the specific parameters | entered for these nodes the green-shaded areas will hear 
the node under review at approximately 9.5uV (-87.5dBm, 7.5dB above the receive sensitivity) and the 
yellow area at about 3uV (-97dBm, 2d0B below the limit of the receiver sensitivity). 


| was interested in connecting this cluster of nodes to a high-ground “backbone” node recently placed 
near M t Palomar, a 5000’ + peak directly to the east. 


The analysis proves out the viability of the prospective link with amore than ample fade margin of 
26dB. The author normally considers a margin of 15dB or more as adequate in most instances. 

W hether this is achievable is highly dependent on the RF environment the node is being placed. Under 
ideal circumstances you want to take advantage of the full receiver sensitivity (approx. -95dB m for 
most U biquiti devices). But this may not be possible if there is in-band competing activity from other 
nodes, or other RF sources. For any given situation, it is the signal-to-noise ratio (SNR) that is 
important, not the signal strength above the receiver's sensitivity. SNR is also expressed in dB. For 
example, if the noise floor at a given location is -85dB, then you would need a received signal strength 
of -70dB m in order to achieve an SNR of 15dB. Remember that Radio M obile, or any other predictive 
software is not knowledgeable of the noise environment you will encounter. So uncertainty will 
remain until you visit the prospective site and confirm this variable. 


© -— FC A © weweplus.org/mw/raniine hte = 
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Power Density 


As hams we generally don’t concern ourselves with too much with power density. Common 
modulation techniques such as CW, SSB, AM, FM arerelatively narrow, but that’s not the case with 
802.11b which uses direct sequence spread spectrum (complementary coded keying - CCK) or 
802.11a/g which utilize orthogonal frequency division multiplexing (OFDM). The AREDN software 
allows user-selectable bandwidths of 5, 10, and 20 M Hz. 


So why would a user want to reduce the bandwidth... and the corresponding maximum throughput of 
the link? The answer is, to increase the signal-to-noise ratio. Each halving of the bandwidth will 
improve the SNR by 3 dB. Therefore, going from 20M Hz to 5M Hz has a6dB improvement. This can 
easily represent the difference between a reliable link and problematic one. 


Fresnel Zones 


One more technical concept you need to be cognizant of is Fresnel (pronounced “fren-|”) Zones. They 
are imaginary oblong lines which emanate from one node to another resembling an elongated cigar. 
The primary cigar represents an area within which interfering objects will cause destructive signal 
reflections at the receiving end. This is also referred to as “multi-pathing.” The formula for 
computing this area is closely approximated by the following simplified formula: 


\ i [ Om | 


: ae D (in miles) 
r (in feet) = 4f (in GHz) 


This zone should be clear of all obstructions, including vegetation. If your modeling exercise is not 
playing out in the real world, the likely culprit is an obstruction in the Fresnel Zone. Notably, the 900 
M Hz band is tolerant of some vegetation in this zone. 


For those less mathematically adept, here are some examples: 


900 MHz at10 miles=60’ 900 MHz at 20 miles =85’ 
2.4 GHz at 10 miles = 37’ 2.4 GHz at 20 miles = 52’ 
3.4 GHz at 10 miles = 31’ 3.4 GHz at 20 miles = 44’ 
5.8 GHz at 10 miles=24’ 5.8GHz at20 miles = 33’ 


Conceptual AREDN Network Implementation 


Below is aconceptual layout of an AREDN network’s core nodes: 
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While the term “mesh networking” implies a peer relationship between nodes, a structured core of nodes 
is defined to establish an initial, predictable path for the network. Three node types are illustrated. 


e Ham-Deployed Last M ile Node: As the name indicates, this node is carried by the Ham deployed 


to a served-agency location requiring the pre-established data services. The “Go-K it” is 


comprised of a 2.4 GHz node, or for longer, outlying areas a 900 M Hz node with a high-gain 
antenna pointed at a Mid-Mile Node. The kit also contains a WIFI router to provide network 


access for the local devices on site. Batteries or a generator powers these devices. 


e Mid-Mile Node: This node is either fixed or vehicle deployed as necessary and per the specific 
network's design. It forms a “reachable” collection point for surrounding Last M ile Nodes and 
has the required higher-gain antenna to reach a higher-ground based Backbone Node. Sector 


antenna(s) allow broad downstream accessibility. 


e Fixed Backbone Node: These nodes are permanent installations that extend the mesh to the 
extreme corners of the planned coverage area. For reliability they operate on the least congested 
band and are optimized for data throughput. Again here, sector antenna(s) are utilized to 
maximize their downstream accessibility to M id-M ile N odes. 


Deployment Challenges 


One of the most challenging aspects of a mesh implementation is inter-connecting “mesh islands” that 
have formed in the more-easily meshed areas. Without a competed mesh network, it is difficult to 
justify the expense/effort of building out network services (email, V oice-over-IP (V olP) telephony, web- 
based utilities, etc.) which are needed to demonstrate the network to prospective EMCOMM clients. It 
may also be difficult to justify the expense of acquiring strategic high-ground properties necessary to 
connect the mesh-islands. 
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The interim solution AREDN has provided is based on Internet tunneling. This involves setting up an 
encrypted tunnel between one tunnel server-node and one node in each of the other mesh-islands. This 
has the effect of connecting all participating mesh-islands together in the same network. In doing so, 
you can gain the benefits of having completed the network and, at the same time justify the build-out of 
|P-based services for the users and demonstrate the utility to prospective customers. 


While tunneling is an effective way to gain that critical mass, it is a poor strategy for EMCOMM 
deployment and should only be used as a temporary means of achieving a specific goal. Tunnels will 
likely not be functional in a real disaster. 


A Roadmap for the Near Term 


The AREDN Development Team recognizes that the following important improvements are warranted 
and is commitment to the advancement of this technology. 
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A More Advanced GUI - More advanced users have taken to other network devices in deploying more 
sophisticated network topologies. Weare committed to providing an optional, more advanced GU| to 
allow for the configuration of these progressive designs. The effort will preserve the auto-configuration 
features for the non-network savvy Hams. 


Network M anagement with SNM P - Utilizing the Simple Network M anagement Protocol, the AREDN 
network should be manageable using any number of standard tools in use today. Customized MIBs 
(M anagement Information B ases) will be developed specific to this technology. 


These tools will allow visualization of the mesh against a map background, see the network throughput 
at a node-interface level, locate choke points within the network that would benefit from improved RF 
quality and bandwidth, and be alerted to segment outages. 


Quality of Service (QoS) - Critical traffic needs priority. EMCOMM data during a disaster must not be 
hampered by casual traffic. Therefore, some form of Quality of Service is warranted. We are not 
certain how this would best be implemented, but will likely require some advanced configuration or 
certification at the user-level. 


Operations outside of the ISM bands - The available Ham band is broader than the U biquiti and TP Link 
devices support in their manufactured form. There would be great value in moving the device off the 
|SM -portion of the band in terms of reduced interference and higher resultant SNR. Weare exploring 
this and believe this will be possible. 


Preserving the 3.4 GHz band - Having recently released software supporting devices in the 3.4 GHz 
band, the team is just coming to realize the huge asset this band represents. This band has no 
commercial allocation in the US and is considered to be in jeopardy of loss to commercial interests. 
W ith the exception of some military radar, there is little interference, making it the quietest of 
alternatives. A Ham presence, particularly in the EMCOMM space, could prove useful in retaining it 
for Ham purposes. 


AREDN Team Developed Deployments - The number of network deployments utilizing this technology 
are too numerous to list, however it is fair to say that groups in most major US cities are, ata minimum, 
exploring this technology as well as major cities in Canada and Europe. 


W here 2 years ago | was begging for speaking opportunities, they now approach me. | am certain we 
are past the tipping point. 


How One Gets Involved - M ost local deployments start at a grass-roots level. It is an excellent way to 
span the gap between radio and computer technologies... and, if approached correctly, can attract a new 
generation to Ham Radio. Larger implementations deserve a network specialist, so | encourage you to 
find one early. Hams tend to become overwhelmed with the networking elements, so having someone to 
offload that worry lets Hams worry more about the radio aspects of this technology than the data. 
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There is a fabulous getting-started primer entitled “Wireless N etworking in the Developing World” 
which | encourage anyone interested in this technology to read. It is available for free as a PDF 
download at: www.wndw.net. 


Conclusion 


There are a variety of mesh network systems today. AREDN is unique in that it operates under Part 97 
under the authorizations inherent in our A mateur license grant. It is easy to configure and is deployable 
by typical hams to served agencies without any knowledge of data networking or the design of the mesh 
to which a node is being connected. It can be used to provide a variety of |P-based services or to restore 
failed intranet-based agency services. 


The AREDN Project team provides support via its website at www.aredn.org to Emcomm groups 
wishing to deploy this technology. 


TheAREDN logo is acopyright of Randy Smith, WU 2S, and is used with permission. 

B roadband-H amnet is a trademark of the Broadband-H amnet, Inc. 

airM A X, NanoStation, airGrid, Bullet, and Rocket are trademarks of U biquiti Networks, Inc. 
TP-LINK and Pharos are trademarks of TP-LINK Technologies, Co., Ltd. 


TheAREDN software is distributed and licensed for use under the Free Software Foundation’s General 


Public License, GPLv3 license. A copy of that license and source is available at the project’s web site: 
http://www.aredn.org. 
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Feher M odulation 16 QAM 


Patrick J ungwirth, PhD 
US Army RDECOM 
Aberdeen Proving Ground, MD 21005 


Abstract 


We present simulations of conventional quadrature amplitude modulation (QAM) and Feher-QAM to 
estimate the bandwidth improvement for Feher-QAM. We show more than a 10% improvement 
(reduction) in bandwidth for Feher-QAM over conventional QAM. We also show the power spectral 
density for Feher-QAM has a much faster convergence than conventional QAM. 


Conventional digital modulation techniques are limited by embedded rectangular windowing functions. 
Some more advanced modulation techniques utilize raised cosine windowing functions (filters) to improve 
sidelobes. Feher modulation uses a half cycle raised cosine waveform to reduce bandwidth and improve 
sidelobe attenuation. Feher modulation offers the equivalent power spectral density convergence of a 
raised cosine windowing function with twice the width (half the bandwidth). All symbol transitions in 
Feher modulation are smooth and occur at zero slope points. The smooth, zero slope transitions help 
improve intersymbol interference, and reduce timing jitter problems. 


Key words: Feher modulation, QAM, Feher-QAM 


1. Introduction 


We present a short introduction to Feher, half cycle raised cosine, modulation. Feher modulation consists 
of half cycle raised cosine functions concatenated together to form a smooth function. For the symbol 
sequence {@, 1} astep change occurs when transitioning from @ to 1 in conventional modulation. In Feher 
modulation, the symbol transition occurs over a full symbol time. The sequence {@, 1} is mapped to a 
positive going half cycle raised cosine waveform, -~, with gain = +1 in (1.1). The sequence {1, @} is 
mapped to a negative going half cycle raised cosine waveform, ~, with gain =-1in(1.1). The sequences 
{@, @} and {1, 1} are mapped to a zero slope line segment, —, as shown by gain =0 in (1.1). 


Gain =-1 Gain =0 Gain =+1 


Half Cycle Raised Cosine 


(basis function) NS, a (1.1) 


The mapping of serial data {@, 1, 1, 1, @, 8, 1} to Feher modulation is illustrated in Figure 1.1. The initial 
symbol (condition) is assumed to be @. The 9% to @ transition is mapped to a zero slope line segment 
(where e* is the assumed initial symbol). The next symbol transition is @ > 1 whichis mapped to a positive 
going half cycle raised cosine waveform, -~. The 1 1 transition is mapped to a zero slope line segment, 
—, The1+1,1 0,0, and @ > 1 mappings are also shown in Figure 1.1. As illustrated in Figure 1.1 
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F eher modulation is a smooth function with zero slope points occurring at the serial data symbol transition 
points ( ). Figure 1.1 also shows that each half cycle raised cosine waveform 
(gain =-1, 0, and +1) occurs over one serial data symbol time. 


Serial Data 


By eer Feher Modulation 


Smooth, Zero Slope Transition Points 


—> [1|) > 


Bit Transitions 


1-1 1-1 


Initial Condition is 


Figure 1.1. Feher Half Cycle Raised Cosine M odulation 


2.0 W indowing Functions 


Equation (2.1) introduces the unit step function. The unit step function is used to create the rectangular 
windowing function in (2.2). Equations (2.2) through (2.5) introduce a number of windowing functions. 
When data is sampled over a finite length of time, the resulting function is equivalent to a rectangular 
windowing function times an infinitely long function. The rectangular windowing function has slow 
(poor), dB( f) = 20log (2), power spectral density convergence as illustrated in Figure 2.1. To 


improve the convergence of sampled data, a raised cosine windowing function is used to reduce the effects 
of the rectangular windowing function. 


For the serial data stream in Figure 1.1, the step changes embed rectangular windowing functions in the 
serial data’s power spectral density [1-5]. From a practical point of view, Feher modulation minimizes 
the slope when transitioning from serial data symbol, n, to the next serial data symbol, n+l. Full cycle 
raised cosine modulation, and overlapped raised cosine modulation are described in [6-8]. 


The half cycle raised cosine windowing function (2.5) has the same power spectral density convergence 
as a raised cosine window with twice the width (2.4). In section 4, simulations are used to determine the 
bandwidths for conventional quadrature amplitude modulation, and Feher-QAM. We will show in 
sections 4 and 5 that the half cycle raised cosine windowing function results in more than a 10 % reduction 
in bandwidth for 16 quadrature amplitude modulation. 
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Unit step function, u(t) (2.1) 


Rectangular windowing function (width = 2) 


Wrec(t) = u(t+ 1) —u(t — 1) (2.2) 


Raised Cosine windowing function (width = 2) 
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0 otherwise 


Raised Cosine windowing function (width = 4) 
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Figure 2.1. Windowing Functions 
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3.0 Quadrature Amplitude M odulation (QAM ) Background 


Quadrature amplitude modulation(QAM) — /(¢) and Q(t) values are found in the 
diagrams in Figure 3.1 and Figure 3.2. (3.1) 


s(t) = I(t)cos(2nf,t) — Q(t)sin(2Tf,t) f =carrier frequency in Hz 


Equation (3.1) provides the general definition for quadrature amplitude modulation. Cosine and sine terms 
are multiplied by I(t) and Q(t) signals respectively. The term I(t) is in-phase with the cosine carrier and 
Q(t), the quadrature phase term, is 90°( = radians) out of phase with the cosine carrier. Figure 3.1 presents 
the constellation diagram for 4 level QAM which is equivalent to 4 level phase modulation. We see the 
points on the constellation diagram all have a radius of 1 with phase angles at +45° and +1352 ( =" and ==" 
radians). The angle sum identity shows 4 level QAM reduces to phase modulation. This is a special case; 
in general the | and Q terms create both amplitude and phase modulation. 


Quadrature Phase, Q(t) 


In-Phase, I(t) 


cos( 2nft+@) =cos(@)cos( 2nft) - sin(p)sin( 2nft) 


Figure 3.1. 4 Level QAM or 4 Level Phase M odulation 


Message = “DSP” = 0x44; 0x53; 0x50 (where 0x##indicates a hexadecimal number) {3.1} 


We present an example message = “DSP” to show how ASCII characters are converted to 16 level 
quadrature amplitude modulation. The message “DSP” in {3.1}, converted to ASCII code gives 
‘D” = 0x44, “S” = 0x53, and “P” = 0x50. For 16 QAM in Figure 3.2, there are 16 symbols {0x0, 0x1, 
0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, OxA, OxB, OxC, OxD, OxE, OxF}. Each group of 4 bits from the 
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message “DSP” is converted to a (I,Q) vector representation for 16 QAM modulation. Figure 3.2 shows 
the 4 bit code to 16 QAM look-up table. For “D’=0x44, the 4 bit groups are 0x4; 0x4, the (1,Q) vector 
for 0x4 is (0.75, 0.25) volts. Equation (3.2) shows the (I,Q) vector values for the message in {3.1}. The 
QAM signal, s(t) as shown in (3.1), is calculated from the mth (I,Q) vector and the cosine and sine carrier 
terms. 


Figure 3.3 shows a 16 level QAM modulator block diagram and simulation. Figure 3.3 clearly shows step 
functions present in 16 QAM. The embedded step functions (rectangular windowing functions) result in 
a sin(x)/x power spectral density function as shown in Figure 3.3. 


Message = “DSP” = 0x44; 0x53; 0x50 
“D” = 0x4; Ox4 cS = 0x55 0x3 dE A OS ay 0x0 (3.2) 
on Bee Oooo) EEE] 

(I, Q)in)= (+0.75, +0.25), (+0.75, +0.25); (+0.25, +0.25), (-0.25, +0.75); (-0.25, +0.25), (+0.75, +0.75) 


Quadrature Phase, Q(t) 


16 QAM Symbols volts 
in hexadecimal 
@2 Q3 Q1 ee 
@ @10.55 @ @ 


40:25 40.5 40.75 


In-Phase, I(t) 
volts 


Figure 3.2. 16 QAM Constellation Diagram 


(1,Q)(n) QAM Time Domain Waveform 


symbol |“, “wll [te Output 
Source Modulator 
P ower Spectral Density 


Figure 3.3. 16 QAM Modulator Block Diagram 
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4.0 Feher-Quadrature A mplitude M odulation (QAM ) 


Feher quadrature amplitude modulation (QAM) is similar to the binary example in Figure 1.1. Serial 
binary data consists of two amplitude values +1 and -1 (or 1 and 0). 16 QAM consists of 4 amplitude 
values for | and 4 amplitude values for Q. As illustrated in Figure 3.2, the 4 amplitude values are -0.75, 
-0.25, +0.25, and +0.75. The half cycle raised cosine functions are gain scaled by (4.1) to connect the 
(1,Q) QAM symbols together. For the half cycle raised cosine waveform, the initial value, DC_Offset(n) 
in (4.2), is the final value from the previous symbol. Hrc(t) in (4.3) generates unit amplitude, half cycle 
raised cosine waveforms. Feher QAM in (4.4) isa unit half cycle raised cosine, Hrc(t) in (4.3), gain scaled 
by (4.1), plus the final value from the previous (I,Q) vector in (4.2). 


Gain(n) = (I, Q)(n) - (I, Q)(n-1) (4.1) 


DC_Offset(n) = (I, Q)(r-1) (4.2) 


Periodic Half Cycle Raised Cosine 


a(t) =“MWV Where o(t) is the sawtooth function 


Feher_QAM(t) = Hrc(f) * Gain(n) + DC_Offset(n) (4.4) 


Figure 4.1 shows a block diagram implementing Feher modulation algorithm for 16 QAM. Vector 
operations are shown as thick lines. Scalars are shown by thin lines. The most complicated part of F eher 
modulation algorithm is the unit half cycle raised cosine generator, Hrc(t) in (4.3). The rest of the 
Operations are vector addition and scalar multiplication. A look-up table (Figure 3.2) converts 4 bit 
numbers to 16 QAM symbols. 


Conventional QAM and Feher QAM are compared in Figure 4.2. The half cycle raised cosine waveforms 
form smooth curves from (1,Q)(n-1) to (1,Q)(n). The Feher QAM waveforms are smooth functions without 
step changes. At each conventional QAM symbol transition, Feher QAM has a zero slope. Each half 
cycle raised cosine requires a full conventional QAM symbol time to change state. Figure 4.1 shows a 
Feher 16 QAM modulated waveform. It is a smooth function without any step changes. 


Figure 4.3 and Figure 4.4 compare simulations of conventional 16 QAM to Feher 16 QAM. Figure 4.4 
shows an expanded scale highlighting the main lobes. Conventional QAM has a sin(x)/x power spectral 
density function with a slow convergence. Feher QAM has a narrower main lobe with a much faster 
convergence (cosine-like windowing function). Section 5 compares bandwidth and convergence for 
conventional QAM and Feher-QAM. 
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Figure 4.1. Feher-QAM Block Diagram. 
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Figure 4.2. Simulated QAM and Feher QAM Waveforms 
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Figure 4.4. QAM and Feher-QAM 90% and 99% Power Bandwidth Points 


5.0 Bandwidth C omparison 


We simulated a 1000 Hz carrier frequency, 100 symbol/second conventional QAM modulator and F eher- 
QAM modulator using the simulation tool in [9]. Table 5.1 only compares power bandwidth points for 
the main lobes. As shown in Figure 4.4 the sidelobes for conventional QAM are much larger than F eher- 
QAM. Including the first sidelobes in the power bandwidth calculation would show even a large 
improvement for Feher-QAM. Table 5.1 shows better than a 10 % improvement in the 90 % power 
bandwidth points for Feher-QAM. Table 5.2 shows a 30 dB improvement in power spectral density 
convergence at +2fcym (2 times the symbol frequency). Tables 5.1 and 5.2, and Figures 4.3 and 4.4 show 
improved (reduced) bandwidth and much better convergence for Feher-QAM compared to conventional 
QAM. 


Table 5.1. Bandwidth Points in terms of Symbol Frequency (100 Hz) 


Bandwidth Points Conventional Feher-QAM Improvement 
QAM 

90 % Power Points | +58Hzor+58% | +50Hzor+50% 13.8 % 

99 % Power Points | +80Hzor+80% | +75Hzor+/5% 6.3% 


Table 5.2. Convergence in terms of Symbol Frequency (fsym) 


Symbol Conventional Feher -QAM Improvement 
Frequency QAM 

+2fsym - 7 dBm/Hz - 37 dBm/Hz 30 dB 

+Afeym -15 dBm/Hz -56 dBm/Hz 41 dB 


6. Conclusion 


We show that Feher-QAM has better than a 10% improvement in bandwidth and 30 dB improvement in 
power spectral density at +2fsym (2 times the symbol frequency). Feher modulation simply adds an 
additional DSP stage prior to the final modulation stage as shown in Figure 4.1. Feher modulation is a 
general technique and can easily be applied to other digital modulation techniques. 
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2015 ARRL/TAPR DCC 


Update on 
DATV-Express exciter 
for Digital-ATV 


by 


Ken Konechy W6HHC 
W6HHC@ARRL.net 


DATV-Express rat 


Abstract - The old technology of analog-ATV suffers from 
susceptibility to snow and multi-path ghost images. Digital-ATV 
(DATV) using new technologies like digital modulation, and 
Forward Error Correction (FEC) can result in robust video reception 
where analog-ATV fails, as well as providing more narrow 
bandwidths on the ham bands. This presentation will review 
progress by the DATV-Express Project Team since DCC2014. These 
new efforts include: 


Making the exciter more portable by Hardkernel ODROID U3 
Single-Board-Computer 


Support of Narrow-BandWidth DATV down to 0.5 MHz 
Using Express_ Server software to provide video by UDP 
DatvExpressServerApp software on Windows (no Linux) 
A brief report on MiniTiouner USB-based Receiver Project 
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DATV-Express 


The Presentation Author.... 


Ken W6HHC 


DATV-Express 


Digital-ATV technology allows Video Quality 
to exceed analog-ATV 


Comparison of analog video and an DATV video 
using the same antennas with weak sigs 
(courtesy of G7LWT & GB3HV) 


DATV-Express 


Status of Digital-ATV Today 
*DATV Video Quality can exceed analog ATV 
¢European DATV is very active and growing 


*Australia/New Zealand have lots of DATV activity 
¢*More hams transmit DATV in USA over last 2 years 


*DATV Transmitter was a cost barrier for most in USA 
*Was US$900 up for MPEG/DVB-S Encoder/XMTRs 


*HiDes DATV xmitter now $175, DATV-Express now $300 


¢ Lot of focus today on ‘ham hackable” DATV Receivers 


DATV-Express 


The DATV-Express Team 


¢ Charles Brain - G4GUO Ferring, England 
*Ken Konechy - WOHHC Orange, CA, USA 
¢Art Towslee -WA8RMC_ Columbus, OH, USA 
*Tom Gould - WB6P Portland, OR, USA 
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DATV-Express 


DATV-Express Project 


* Following 4 slides show the status at TAPR 2014 


DATV-Express 


DATV-Express SDR-based hardware board 


DATV-Express 
Overview of DATV-Express System 


Hauppauge PC Processing 
HVR-1900/1950 For DVB-S Protocol DATV-Express 
oa searsnarsoniasa Ubi crd Pes tires BUSA Exciter Board 
Analog (PCI-based) retract dom ot for 430 MHz to 2450 MHz 


=; ni 
NTSC/PAL MPEG-2 Read Program Stream running DVB-S software 


Video-Capture Card 
Vises NY Add Sl Tobles FPGA-based 
jource aca Scramble Extract USB Data 


interlenve FIR Filter 
Rosen Add Convolutional FEC wacuesm DAC 
Audio Code Puncture UQ Modulator 


Source Map to iQ 6 40- 10 Watts 


1 to >10 mw at 1.2GHz 
GUI ( QT4) mt 12GHe 


Typical System Block Diagram for DATV-Express DVB-S DATV Transmitter 


DATV-Express 


DATV-Express board internal block diagram 


Analog Devices 
CY7C68013A-100AXXC Altera Cyclone Il FPGA Dual-DAC (100 MHz to 2.4 GHz) 
crm BPcceramsinp EP2C8T144C8N 4/2 of —_ ane MiniCircuits 
= Extract USB Data DAC LPF YA 
USB2 sus, Sortinto | and Q data streams o> |-stream > -\ > iQ 

_ = 

Contoller FIR Table Le 120 —»-\ Modulator 

— Buffer (FIFO?) | and Q?? ue 


48 MH 
16 -t0- 60 18a Q -stream 
ite streams 
Alternate (ann bus} 20 MHz 


S/R PLL osc 
Silicon Labs 
RF Gain Control 


Allows RF Distortion correction 


12V -to- 5.5V Optional 
an Bay ay: “Ey, ADC From external RF Directional-Coupler Sensor (rectified DC) 


Analog Devices AD7992-0 


Block Diagram for DATV-Express Exciter Hardware Board 
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DATV-Express 


DATV-Express System Specs 


*DVB-S protocol is tested and released 
*AlllQ modulations (QPSK modulation was tested) 
¢Frequency Range: 

70-2450 MHz (Modulator chip specification) 
¢Symbol-Rate: 

- Adjustable: 0.33 to 5 MSymb/second 

*RF output ~ 1-20 mW buffered (SMA connector) 
*USB Video Capture card for NTSC or PAL 
*PC Operating System - first Ubuntu-32/64-bit 


DATV-Express 


DATV-Express Project 


Five areas of progress: 
¢ Software for quaad-ARM ODROID now released 
¢ Support of Narrow-BandWidth DATV down to 0.5 MHz 
¢UDP function using Express Server software 
* DatvE xpressServerApp on Windows (no Linux) 
¢ SIDE BAR - MiniTiouner USB-based Receiver Project 


DATV-Express 


DATV-Express software for ARM ODROID U3 
*ODROID U3 is quad-ARM “micro-PC” at 1.7 GHz 
*Comes with Lubuntu 14.4 LTS (LDE Desktop) 
*DVB-S protocol is now created inside FPGA 

(off-loads the ODROID processing load) 


*ODROID prepares the Transport Stream (TS) and 
hands off to the FPGA 

¢ Charles G4GUO explains that now DATV-Express 
project has released for ARM...it should work OK 
with almost any ARM product 

¢HardKernel has replaced model U3 with C1+ & XU4 
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DATV-Express 


Hardkernel ODROID U3 “micro-PC” 


ODROID U3 is about the same size as Raspberry Pi 
14 
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DATV-Express 


Hardkernel ODROID U3 


DATV-Express 
Configured for DVB-S 
ODROID U3 


ENS | quadcore ARM “micro-PC” FPGA-based 
fan ol pDseo.. Read TS 

I USB2 USB2 Lubuntu v14,04 OS 

Mouse : Encode DVB-S 
j Mouse —,! _HUB _lusez quad-core-ARM 1.7 GHz 


Analog ; Prepare TS sg 

i QT4 GUI t ( 
ones FIR Filter 
Sass Hauppauge /Q-Modulator 
Analo MPEG-2 APT 

Audion Encoder T Digital | 


at 1.2 GHz 
Source HVR-1900/1950 H Display | | 


ODROID-U3 draft02 


System Block Diagram for DATV-Express DVB-S with ODROID U3 


DATV-Express a | 


Narrow-Bandwidth DATV with DATV-Express 

¢ UK OfCom has allowed temporary use DATV on 2M 
Previously unused 146.0-to-147.0 MHz now allows digital 
DATV is being sent with Symbol Rate typically 333 KS ymb/s 
Typically use H.264 video compression for 15 - 20 Frames/sec 
RF BWallocated =0.5 MHz - Typically centered 146.5 MHz 


Selectable DATV-Express FPGA code uses x64 interpolater 
for 100K to 400KS ymb/sec 


Commercial DVB-S RCVRs only go down to 1 MS ymb/sec 


New MiniTiouner RCVR project goes 125 KS/s to 27.5 MS/s 
(more details later in presentation) 
16 


DATV-Express run 


DATV-Express Narrow-Bandwidth DVB-S of 0.5 MHz 
Spectrum Analyzer span is 2 MHz 
(courtesy of G4GUO) 
17 


100 Hz 


DATV-Express 


UDP feature using Express Server 
* Express Server software was written by Charles G4GUO 


Better control for the receiving of UDP packets by the 
computer connected to the DATV-Express transmitter board 


Configure DirectS how filters using GraphS tudioNext graphs 
Can use LogiTech C615 webcam on Windows 
MainConcepts filters provided MPEG-2 encoding 

S oftware encoder filters eliminate Hauppauge video-capture 


MajorUDP-Sender filter aims UDP to computer connected to 
DATV-Express 
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DATV-Express 


UDP feature using Express_ Server 


DATV-Express board 
: Configured for DVB-S 
Windows Notebook ODROID U3 


Logitech uss 32-bit or 64-bit quadcore ARM “micro-PC” FPGA-based 


Seats Windows? or 8 Lubuntu v14.04 Read TS 
camera ; Encode DVB-S 
Run GraphStudioNext Express_Server protocol 
Logitech MPEG-2 Encoders Prepare TS FEC 


boom-mike MajorUDP sender no GUI FIR Filter 


Headset USB2 cross-over HOM! 1/Q-Modulator 
ETHERNET 


cable DVB-S 


1 to >10 mW 
at 1.2 GHz 


Block Diagram for sending — web cam video by UDP to ODROID 
running Express_Server 
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DATV-Express 


UDP feature using Express_ Server 


File View Play Graph Favorites Options Help 
Sl mw ble! =r | PA] dl 4h > tl» |[a00% | | 


00:00:00.000 / 00:00:00.000 | 
l 


2) CC Input 
MainConcept 
MPE: 
Video Encoder pa 
Input2 
MainConcept 
(HCW) MPEG 
Multiplexer-Plus 


aims UDP packets to 
ODROID IP-address 
GraphStudioNext filters for using C615 webcam on Windows 
MajorUDP-Sender software block is aiming packets to ODROID IP address 


DATV-Express = | 


Using DatvExpressServerApp on Windows 
DatvE xpressServerApp software written by Charles G4GUO 
DatvE xpressServerApp runs on Windows system 
NO LINUX involved 
Use DirectShow filters using GraphStudioNext graphs 
Can use LogiTech C615 webcam on Windows 
MainConcepts filters provided MPEG-2 encoding 
MajorUDP-Sender filter aims UDP to loop-back IP-address 
DatvE xpressServerApp provides a simple GUI 


DatvE xpressServerApp software is still in a highly 


“experimental stage” 
21 
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Using DatvExpressServerApp on Windows 


Windows Notebook DATV-Express board 
32-bit or 64-bit Configured for DVB-S 


Logitech USB2 . 
C615 Web Windows7 or 8 FPGA-based 
Camera Run GraphStudioNext Read TS 
MPEG-2 Encoders Encode DVB-S 
MajorUDP-Sender protocol 
DatvExpressServerApp FEC 
. adds NULL Packets ‘ 
Logitech  yspe Prepare TS FIR Filter 
boom-mike simple GUI 1/Q-Modulator 


Headset 
DVB-S 
1 to >10 mw 
at 1.2 GHz 


Block Diagram showing the DatvExpressServerApp software runs 
completely on Windows machine and connects to DATV-Express board 
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DATV-Express 


Using DatvExpressServerApp on Windows 
SB. 


eal ManConcess 
= UDP addr is — 
set toloopback) 
127.0.0.1 : 


Tame 


fue i ie _s = a 
Windows running GraphStudioNext graphs and 
simple GUI for DatvExpressServerApp 
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Using DatvExpressServerApp on Windows 


# | MainConcept (HCW) MPEG-2 Video Encoder Properties 


| [About | Man Settings | advanced Settings | Fiter | interfaces | input | Output | * | ¢ 


Properties of MainConcept video encoder filter using 
ConstantBitRate (CBR) 
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DATV-Express run 


Using DatvExpressServerApp on Windows 


V1,01, bud 20060501 | About | Filter | Interfaces | Inout 


in UdeConnect, 2 
TMaqor ndinpulPin UdeDieconnec 
TMaprUdpSendinputPin UdpCornmect, Host 1270.01, Port 1 


127007 
1988 


Meds samples tecerved 14129140 
Mecha samples tend 14125568 


Properties of MajorUDP-Sender software with IP destination address 


aimed at loopback 127.0.0.1 and socket chosen for an arbitrary 1958 
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DATV-Express = | 


MiniTiouner USB-based Receiver Project 
¢ | ean Pierre FODZP created DVB-S/S2 analyzer software 
¢ “Digital transmissions are not really all-or-nothing - 
in between there are many things that can happen” - F6DzP 
* Original TuTioune software used PCl-based hardware 
¢ New MiniTiouner receiver project is USB-based 
¢ Software is “ham hackable” to allow fitting DATV needs 
¢ Symbol Rates can be from 125 KSymb/s to 27.5 MS ymb/s 
¢ | ean Pierre F6DZP created software and schematic design 
¢ Brian G4EW) prepared PCB layout and gerber files 
¢ BATC team sells kits on BbIG Online Store 
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DATV-Express 


MiniTiouner USB-based Receiver Project 


a = py! 
9000000000000 wt - \ 


MiniTiouner USB-based Receiver is “ham hackable” 
(photo courtesy of G4KLB) 
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DATV-Express 


MiniTiouner USB-based Receiver Project 
Weltli ees fee 


TiTioune i Is DVB- S/DVB-S2 quality analyzer 
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Conclusion and Plans 


¢ DATV-Express is now released for ODROID ARM CPU's 


¢ There were “handcuffs” that limited interest and applications: 
¢ Linux - steep learning curve or hams with “no interest” 
¢ NTSC/PAL cameras were old (becoming obsolete) 
* Hauppauge HW video encoders are difficult today (no linux) 


DatvE xpressServerApp on Windows allows “escape handcuffs” 
New cameras (webcams, etc) can be selected for GraphStudioNext 
UDP opens many opportunities for remote video streams 
USB-based MiniTiouner RCVR project solves DATV problems 
Open project source code repository - - see URLs atend 
PLANS ? - “so many ideas, so little time” 


DATV-Express 


* British ATV Club - Digital Forum 
www.BATC.org.UK/forum/ 

*CQ-DATV online (free monthly) e-magazine (eP ub format) 
www.CQ-DATV.mobi 

*OCARC library of newsletter DATV articles 
www.W6ZE.org/DATV! 

* TAPR Digital Communications Conference proceedings (free downloads) 
www.TAPR.org/pub_dcc.html 

* Yahoo Group for Digital ATV 
http://groups.yahoo.com/group/DigitalATV/ 

* DATV-E xpress project website 
www.DATV-Express.com 

* G4GUO github for DATV-Express source code 
https://github.com/G4GUO/datvexpress_gui.git 

* G4GUO github for express_server source code 
https://github.com/G4GUO/express_server.git 

* Hardkernel (Korea) for ODROID model U3 ARM-based “micro-PC” 
www.hardkernel.com 

¢] ean Pierre F6DZP web site for TiTioune and MinTiouner 
http://vivadatv.org 
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Measuring the lonosphere at vertical incidence using Hermes, 
Alex, and Munin Open HPSDR and Gnuradio. 
Tom McDermott, N5EG, n5eqg@ tapr.org 


Key words: Monostatic, lonosphere, Doppler, Correlation, HPSDR, Gnuradio 


Abstract 


This paper describes a monostatic method for measuring the vertical virtual height and the vertical 
velocity of the F-layer of the ionosphere. The equipment is simple and relatively low power, it uses the 
Open HPSDR Hermes transceiver module, Munin broadband Power Amplifier (PA), and Alex RF filter 
module. The antennas consist of a 40m dipole and antenna tuner for transmit and an active receive 
loop antenna. The software real-time processing (reception, windowing, and correlation) is done using 
Gnuradio on a Linux PC, followed by post-processing using a Python program (multiple sweep 
integration and plotting). 


lonosphere 


Figure 1 shows typical critical frequency for the E- and F layers versus local time of day. While the 
MUF depends on the angle of incidence to the ionosphere, the critical frequency is defined at vertical 
incidence. Generally measuring the E-layer requires using the 160m band (except occasionally near 
noon during the summer at lower latitudes it may be possible to use 80m). Measuring the F 2-layer 
critical frequency can be done on the 80m band much of the day, and sometimes on the 40m band. 
When measuring the F-layer, the higher the frequency used the less the F-layer echo attenuation 
caused by transiting the E-layer twice. 
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Figure 1 - Typical Critical Frequencies for E- and F- layers, summertime, 40 degrees N, Solar time, Sunspot 
Number = 86 
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Figure 2 - Basic setup - Transmitter and Receiver Co-located. 


The ionosphere reflects vertically incident signals below the critical frequency. The time-of-flight of the 
go plus return signal indicates how high the ionospheric layer is. Additionally the ionosphere layer 
may have a vertical velocity (either upwards or downwards) that induces Doppler shift onto the 
reflected signal. Figure 2 shows the basic setup -transmit and receive antennas are located within 
about 100 feet of each other - this is known as a monostatic radar configuration. 


Chirp Measurement Approach 


Practical measurements pose some difficult requirements because the echo is delayed less than one 
millisecond (E-layer) or about 1.6 milliseconds (F-layer). The monostatic approach also means that 
the transmit signal will be much stronger than the received signal, thus the receiver dynamic range 
must be large. 


The approach chosen for these experiments was to transmit a linear FM chirp signal and correlate the 
received signal against the signal used to drive the transmitter (matched filter approach). The number 
of correlation taps is large in order to provide enough dynamic range and time resolution to see echos 
approximately 100 dB below the transmit signal. This approach requires full-duplex equipment -the 
transmitter and receiver are operational simultaneously. If the transmitter and receiver are co-located 
the transmit signal tends to overload the receiver which is listening to the same frequency at the same 
time as the transmitter is operating. The current experiment uses co-located Tx/Rx (Same circuit 
board) and Tx/Rx antenna having about 20 meters separation. A similar experimental approach using 
60 meters of Tx/Rx antenna separation was previously demonstrated by the Institute of S olar- 
Terrestrial Physics!. The low-phase-noise and good ADC dynamic range performance of the Hermes 
receiver helps minimize receive noise that would otherwise obscure the desired receive echo2. Chirp 
modulation is discussed in some recent amateur radio literature?. 


A linear FM-chirp signal is a constant-amplitude signal that sweeps in frequency at a constant rate. At 
the end of the sweep the signal returns back to the start frequency and sweeps again. For example, 
an up-chirp could sweep from -fy KHz (below the channel center frequency) to +fy KHz (above the 
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channel center frequency), then ‘snap’ back to -fy KHz and start again. It’s also possible to turn off the 
transmit signal for a short period of time during the retrace. The turn-on and turn-off parts of the signal 
are amplitude ramped with a raised-cosine waveform in order to prevent spectral transients. A down 
chirp is just the opposite, it starts at a frequency above the channel center and sweeps down ata 
constant sweep rate to below the channel center frequency. 


The received signal is correlated against a stored version of the transmit signal. In effect the DSP 
correlation filter is performing as a matched filter of the chirp signal. When using a chirp to measure 
the ionosphere we are interested in searching for a weak replica of the chirp delayed by some amount 
of time related to the propagation delay, equipment delay, and frequency shifted due to the Doppler 
shift induced by the vertical movement of the ionosphere. Doppler shift of the received echo has the 
effect of appearing to alter the time delay (and thus the virtual height measurement) of the received 
signal. The effect of Doppler is equal and opposite for an up-chirp signal compared to a down-chirp 
signal. By transmitting both kinds of chirps, and analyzing them independently, we can compensate 
for the Doppler-induced range (height) error and additionally, measure the amount of Doppler shift 
induced thus allowing computation of the vertical velocity of the ionosphere. Figure 3 shows reception 
of an Up-chirped signal with no Doppler shift. Figure 4 shows reception of an Up-chirped signal with 
(+) Doppler shift, and Figure 5 shows reception of a Down-chirped signal with (+) Doppler shift. 


Time delay due to 
ionsopheric height, 
no Doppler shift. 
The Range or 
Height of the layer. 


frequency 


time 


Figure 3 - Up Chirp reception with no Doppler shift. 


Notice that the Up-Chirp and Down-chirp exhibit opposite range errors. This allows us to resolve the 
correct range and the amount of Doppler shift. The amount of range error caused by Doppler shift is 
dependent on the chirp rate. 


The range to the ionosphere (the height) is proportional to half of the round-trip time. 
Range (Height) = c « weet (1) 


Where c is the speed of light in m/s, and tis the time of the echo, in seconds. To compute the range 
error caused by Doppler, the formula is: 
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Range Error = c * “ (2) 


Where d is the Doppler shift in Hz, and s is the chirp sweep rate in Hz / second. 


Causes Range 
error due to (+) 
Doppler shift 


frequency 


(+) Doppler shift due 
to falling ignosphegi 
layer (approaching 


time 
Figure 4 - Up Chirp Reception with Positive Doppler Shift due to falling ionospheric layer. 


For example a chirp rate of 15,000 Hertz/second implies an equivalent range error of 19.919 km per 


Hertz of Doppler shift. The vertical velocity of the ionosphere is measured by the induced Doppler shift 


which we infer from the range error. 


Doppler Shift = s * Le Lees (3) 
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Figure 5 - Down Chirp Reception with Positive Doppler Shift due to falling ionospheric layer. 
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Note that the vertical movement of the layer induces a doubled Doppler shift. The chirp signal hits a 
moving ionosphere layer, thus being Doppler shifted as received by the ionospheric layer. Then the 
signal is re-emitted by the ionosphere and received back at the ground thus inducing another Doppler 
shift. Doppler shift is related to the layer velocity and the frequency of the radio wave, adding the 
factor of two for reflection from a moving ionosphere. 


A 
Af =2*—* fy (4) 
We compute the velocity of the ionosphere as: 
Af * 
Av = 25 (5) 
2 * fo 


Relating the velocity to the measured range error: 


hoe s* Range Error (6) 
2 * fo 
We measure the range error by measuring the difference between the ranges determined by the up- 
chirp and the down-chirp time measurements. Since each chirp introduces an equal and opposite 
error, the actual range error is the difference divided by two. 


hs s * (UpRange—DownRange) (7) 
2 * fo 
A slower chirp rate yields higher sensitivity to Doppler shift allowing more resolution of the ionosphere 
Doppler and thus the ionosphere vertical velocity. 


Signal Processing 


The basic receive algorithm consists of cross-correlating the received signal against a stored replica 
copy of the transmit signal. This is known as a matched filter. It provides a couple of benefits: 


e The actual transmit signal strongly correlates with its own replica providing a convenient way 
to compensate for fixed equipment delays. 

e A weak echo is easily seen above the background noise even in the presence of a strong 
transmit signal. 

e The delay of the echo signal is the difference in time between the received transmit peak and 
the received echo peak. 


This removes the requirement of knowing the absolute delay through the radio, Ethernet switch, and 
DSP processing - such errors or unknowns are subtracted out. 


The DSP algorithm that correlates the received signal with the replica is factored through several 
steps in order to improve the computational efficiency. We define the two signals, f(t) (transmit replica 
copy) and g(t) (received signal). The circle-plus means convolution, and the circle-cross means 
correlation. The convolution of f(t) with g(t) is defined as: 
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f(t) B g(t) = ff) * gt -1) dt (8) 


Convolution is implemented in DSP using an FIR filter kernel. A ready-made DSP block exists within 
Gnuradio that directly implements an FIR filter. Correlation is closely related to convolution, the filter 
taps need only be time-reversed to implement cross-correlation. The cross-correlation of f(t) with g(t) 
is defined as: 


If @ gl (t) = [°° f-1) * g(t—a) dt (9) 


We need only time-reverse the stored replica copy of the transmit chirp signal before introducing it as 
the taps of the FIR filter. It’s less efficient to time-reverse the receive signal because it would require 
buffering the received signal first. We don’t need to write any code, we can simply use Gnuradio’s 
existing FIR filter and just read in the taps from a file containing the previously stored time-reversed 
chirp signal. 


It is not possibly to actually compute an infinite number of taps, but some finite number of taps. 
Unfortunately an FIR filter requires on the order of N2 operations, abbreviated O(N2). This means that 
if we try to implementa correlation of 1 million taps (10°), the correlation operation requires on the 
order of one trillion (1012) computation cycles which is infeasible. Both the signal and the taps are 
complex numbers (I and Q), requiring at least four floating-point multiplies and two additions per tap. 


Fortunately there is a much more efficient way to implement the FIR filter in the frequency domain 
using the FFT (Fast Fourier Transform). This is called an FFT filter and itis also a built in block in 
Gnuradio, so we don't need to write it. The correlation can be implemented by taking the FFT of f(-t) 
and the FFT of g(t) and then pair-wise multiplying each element of f and g. Finally we take the inverse 
FFT of the result to get back to the time domain. This sounds more complicated than a direct FIR, but 
the FFT operation is extremely efficient such that the FFT filter requires far fewer computations, on 
the order of O(N log2 N) operations. Fora 1-million element correlation, this is on the order of 18 
million operations (2 FFT and 1 IFFT) compared to one trillion operations using the direct FIR filter. 


For convolution, 


f(t) ® g(t) = IFFT [ FFT(f(t)) * FFT(g(t)) | (10) 


Similarly to an FIR filter used for correlation, the FFT filter can be used for correlation by time- 
reversing the waveform used for the filter taps. 


f(t) ® g(t) = IFFT [ FFT(f(-t)) * FFT(g(t)) ] (11) 


Properly constructed linear chirp signals have several interesting symmetry properties: an up-chirp 
signal is the frequency conjugate of the down-chirp signal. An up chirp signal is also the time reverse 
of a down chirp signal and vice versa. This means we don’t even need to bother time-reversing the 
stored chirp signal. To correlate a receive echo, we just need to load the FFT filter taps (or FIR filter 
taps) with the opposite type of stored transmit chirp. 


f(t) ® g(t) = IFFT [ FFT (opposite chirp(t)) * FFT(g(t)) | (12) 
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This series of steps (leading to Equation 12) reduces the computational effort required to correlate the 
received signal against the stored transmit signal by an extremely large amount. At 384 k samples per 
second, a Core i7-3770 (3.4 GHz) processor can easily keep up with the 1-million point correlation in 
real time in Gnuradio. In fact, several can be run in parallel to directly compare various algorithm 
tradeoffs. 


Figure 6 is a block diagram of the DSP steps implemented in the flowgraph. The FFT taps utilize a 
stored version of the chirp waveform created at 384 ksps, so no decimation is performed in the 
receive chain of the active flowgraph. There are very few steps required. The time domain output of 
the correlation filter is stored as a file on disk (File Sink) for later post processing in Python (receive 
integration). 


Receive Lowpass Shaping Filter (Windowing in the Time domain) 


In the previous figure the signal received from Hermes is first lowpass filtered in the frequency domain 
before being applied to the correlation function. This lowpass filter has a gentle shape defined with a 
Blackman-Harris window. The shaping in the frequency domain results in the time-domain samples in 
the correlation filter being windowed as though by a time-domain window because a linear chirp is 
being received (the frequencies at the extreme positive and negative ends of the chirp are the most 
attenuated). Without this windowing, spectral leakage would obscure the echos. Figure 7 shows the 
correlator output sidelobes with and without receive lowpass filtering. The time delay of the Blackman- 
Harris filtered and the unfiltered signals been approximately normalized with a delay element to 
roughly time-align the two to ease visual comparison in Figure 7. 


Receive Integration 


While the raw algorithm achieves about 110-120 dB of dynamic range, overloading of the receive 
antenna amplifier and other parts of the receiver degrades the dynamic range to about 90 dB. In order 
to bring the received signal up out of the noise, about 10 sweeps of the receive signal are recorded on 
disk. Then the signals are non-coherently averaged. This brings the F-layer echos clearly up out of 
the noise level. 


Figure 6 is the Gnuradio flowgraph used to capture and real-time process the signal. A custom 
Gnuradio block was written to generate a programmable chirp signal. A number of parameters were 
included in that block to permit adjusting the frequency deviation, sweep rate, number of samples per 
Sweep, and providing a raised-cosine start and stop shape. The Chirp block feeds the Hermes 
transmitter port. The HermesNB module was written to provide access to many features of Hermes 
and Alex, and has been previously described’. 


The Hermes FPGA code also filters the transmit signal, it limits the maximum frequency response of 
the transmitter to +20 KHz of the transmit center frequency. 


The reason that the echos are non-coherently integrated is that the Doppler shift induced onto the 
receive signal means that the relative phase of the receive echo changes each sweep of the chirp. If 
coherently integrated the echos would average towards zero. Non-coherently we just integrate the 
magnitude of each echo (neglecting phase). A 3 dB improvement in SNR should be possible through 
echo phase de-rotation and coherent integration. 
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Figure 6 - Block diagram of the Gnuradio chirp transmit & receive data processing flowgraph. 
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Figure 7 - Rectangular (no low pass filter) has high residual correlation sidelobes. A Blackman-Harris lowpass 
filter reduces the sidelobes out past about 0.3 milliseconds. The vertical scale is -50 to +120 dB. 
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Block Diagram 


Figure 8 is a block diagram of the test setup. The Alex module is used as the transmit bandpass filter, 
however it is not used in the receiver path due to insufficient isolation between the transmitter and the 
separate receive connector on the Alex module. Input to the Hermes receiver had to completely 
bypass the Alex module. Gnuradio sends a FM chirp signal of constant amplitude to the transmit 
section of Hermes, and then to Munin (broadband PA) where it is amplified to about 20 watts output 
power. The amplifier output is filtered by the Alex RF filters, and sent to an antenna tuner and 
ladderline and a 40m dipole. For F-layer echos, the transmit signal is about 3.6 MHz. 


Horizontal 
"ee 
alias Hermes | Munin 80m | ATU | 
Transmitter PA BPF 
pssoutea eee 
Hermes = = 
ets Receiver | Gnuradio __ Tipe _ Samples 
[Beer] | LPF ae To File 
— Full Duplex = 2h | | 
Conjugate | Python 


Vertically polarized Chirp Post Process 
Active Rx loop (From file) & Plot 
| = _ Matched filter 
| Ghuradio SW (correlation) 
____ Python sw | 


Figure 8 - Block Diagram of Test Setup. Box colors indicate functions implemented in Hardware, Gnuradio 
software, and Python software. 


Due to the high SWR on the ladderline, about 6 watts of transmit power is actually radiated by the 
antenna, while 14 watts is absorbed by the feedline loss. On receive a homebrew active loop antenna 
1 meter in diameter feeds a differential amplifier and balanced-to-differential transformer through a 
common mode choke. The antenna is remotely powered over the RG-6 feedline. After reception the 
Hermes signal is filtered in Gnuradio through a baseband lowpass shaping filter (to window the 
samples in time) before being sent to the FFT correlator. 


Figure 9 is a photograph of some of the components of the experimental setup, while the RF Alex 
bandpass filters and the Core i7 Linux computer running Gnuradio are not shown in the photograph. 


Figure 10 is a photograph of the active receive loop antenna. Only one of the two loops are used in 


this experiment. The loop antenna is vertically polarized, helping to reduce coupling to the horizontally 
polarized transmit antenna. The antenna was constructed with future experiments in mind where it 
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should be possible to discriminate between the Ordinary-ray (0) and eXtraordinary-ray (X) reflected 
by the ionosphere. 


Figure 9 - Photograph of the test setup, showing DC Power Supply, Munin amplifier, Active loop 
bias-T, Hermes board. Not shown: Alex RF bandpass filter, Computer (outside the photo). 


Figure 10 - Homebrew dual active-loop receive antenna (vertically 
polarized). Only one of the two loops is used in this experiment. 
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Results 


So far measurements have been made on the F-layer at several times of day. The tests were 
conducted at about 3.6 MHz channel center frequency. Before dawn in fall / winter this is above the 
critical frequency, and no vertical reflections were received. In the evening local time the critical 
frequency is usually higher than 3.6 MHz, and vertical reflections have been received. 


Figure 11 is a graph of the up-chirp (blue) and down-chirp (green) signals. It will be noticed that the 
Up- and Down- chirps exhibit range difference due to the Doppler shift of the moving ionospheric F- 
layer. This figure represents about ten sweeps that have been non-coherently integrated. The vertical 
axis is the magnitude of the correlation, in dB while the horizontal axis is time in seconds (spanning 0 
to 5 milliseconds). The transmit peak has been adjusted to zero time by the post-processing Python 
integration program. The primary reflections are seen at about 1.7 milliseconds after the transmit 
peak. There is a spurious peak at 4 milliseconds (and multiples of 4 milliseconds) for both sweeps, the 
cause has not yet been determined. 
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Figure 11 - F-layer reflection at 3.6 MHz in the evening local time. This figure is the correlation integral 
output after post-processing and integrating about 10 sweeps with Python software. The vertical axis is 
dB, the horizontal axis is delay time in seconds. The signals near 1.7 milliseconds are the F-layer 
reflections. Signals near 3.4 milliseconds are double-transit reflections. The signals at 4.0 milliseconds are 
system artifacts. 


At about 3.4 milliseconds, small peaks in the Up- and Down-chirps can be seen. These are double- 
transit reflections - the signals traveled up to the ionosphere, down to ground, reflected by the ground 
back up to the ionosphere, and reflected back downward a second time. Notice that the Doppler 
range error is doubled as well. 


The Doppler induced range errors indicate that the F-layer of the ionosphere is ascending at the time 
of this measurement. 
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The average of the two time measurements is the actual F-layer height, while the difference between 
the two is proportional to 4 times the Doppler shift. The moving ionosphere reflects the signal, thus 
doubling the induced Doppler shift, and the up and down chirps have opposite range errors induced. 
Thus the measured range difference represents quadruple the Doppler shift. 


Calculations from Fig 11 show the F-layer height at 254 km, and the layer velocity at +15.4 meters per 
second (upward). The Doppler shift is about -0.38 Hertz. Both range and Doppler resolution is limited 
by the filters and the correlation width. The half-lobe width is about +17 microseconds, implying a 
range bin size of roughly 5 km. 


Further Work 


Figure 12 shows F-layer reflections that include reception of both the Ordinary (O) wave and the 
Extraordinary (X) waves. With a single receiver and linearly polarized receive antenna itis not 
possible to know which is O and which is X. The current single linearly polarized receive antenna 
sums the Right Hand Circular (RHC) and Left Hand Circular (LHC) components into one received 
signal. The dual-receive crossed linear loops (previously shown) plus two phase-coherent receivers 
(not available to the author at this time) could be used to capture two signals, one per antenna. Then 
the Gnuradio DSP software would be able to synthesize the right-hand and left-hand circular signals 
from the two linearly polarized receive signal components. 
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Figure 12 - F-layer reflection at 3.6 MHz showing Ordinary (O-wave) and Extraordinary (X-wave) reflection 
components from the F-layer near 1.7 milliseconds. The signals at 3.06 and 4 milliseconds are spurious 
artifacts. 


Circularly polarized signals identify which reflection is O and which is X. Since the transmit antenna is 
linearly polarized, it emits a RHC plus a LHC signal simultaneously. These two signals remain 
coupled as one linearly polarized signal until encountering the ionosphere undergoing magnetic bias 
from the Earth’s magnetic field. This causes them to de- couple into independent LHC and RHC 
components, which are the O and X waves. The effective ionospheric refractive index is different for 
the RHC and LHC components, which thus propagate with different characteristics in the ionosphere 
and are received as two different reflections. 
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We can construct the RHC and LHC components from the two received signals. Designating these 
two received signals as RXa and RX» (each complex valued) then: 


RHC = RX, + e/”/*RX,, (13) 
LHC = RX, +e J7/7RX, (14) 
LHC and RHC can be generated at baseband using standard Gnuradio complex multiply blocks. 


E-layer reflections have not been received at this time due to lack of appropriate transmit antenna. 


Thanks to Andrew Martin, VK30E, J ohn Petrich, W7FU, and Phil Harman, VK6PH for helpful review 
and comments. 
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Abstract 


Simple CAT Controller for HPSDR using an Arduino micro-controller and a few switches and a 
step encoder. 


Introduction 


One of the perceived problems of the HPSDR project is that the radios do not have any knobs and 
buttons. PowerSDR has a CAT interface for controlling the radio that uses a serial interface. This 
interface is used by several add on applications that also require control of the radio, typically using 
a Virtual serial port. 


The Arduino micro-controller provides an ideal platform to build a controller with knobs and 
buttons. The basic Arduino UNO is cheap and provides for a number of analog and digital 
interfaces. Simply connectng up a few push switches and step encoders allows us to develop a 
custom controller. 


Basic Design 


A controller can be implemented using an Auduino UNO. These are readily available from several 
on-line resources including EBay. In the UK they can be found as cheap as £5 ($7.50). 
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Illustration 1: Arduino Uno 


The small board has a USB 
connector that is used for 
both programming the 
device and also as the USB 
Serial interface. 


There are a number of digital 
inputs, 2 of which can be 
used to trigger interrupts. 
The digital inputs can also be 
programmed to enable 
internal pull up resistors. 


There is also a power 
connector that is not used as 
the power is taken from the 
USB interface. 
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For this application we want to implement a tuning 
knob. We can use a step encoder. This uses 2 signal 
lines to send a clock pulse and a data pulse. These can 
be used to determine the direction of rotation. I have 
used a KY-040 encoder. These are available as a small 
board as can be seen from the image below. They also 
include a switch that is activated when the button is 
pressed. These again a readily available. I bought 5 of 
them for £8 ($12) in the UK. 


There are 5 connections, CLK, DATA, SW, +5v and 

GND. The CLK and DATA lines had 10K pull up 

resistors on the board. The switch does not but if 

needed there are pads to add one. The encoder generates 

24 pulses per revolution. Illustration 2: KY-040 Step Encoder and 
Switch 


Any SPST push to make momentary switches can be used. To make connection simple I soldered a 
pair of header pins to each switch. For the basic controller I decided on 3 switches. 


Illustration 3: Push switch with 
header pins 


To connect up the components I used some Dupont male to female jumper cables. These usually 
come as a ribbon cable that can be separated. 


Illustration 4: Dupont jumper cables 


All that is needed for the hardware is a box to mount the Arduino UNO in with the step encoder and 
switches mounted on the lid. 


Illustration 5: Prototype Controller 
Circuit Diagram 
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The encoders CLK and DATA lines are connected to digital pin D2 and D3 on the Arduino board. 
Both of these pins can trigger interrupts. This allows fast detection of the steps as it is rotated. 


The switch on the encoder is connected to digital pin D4, and the remaining switches are connected 
to digital pins D5, D6 and D7 on one side and all to GND on the other. All the switches are 
configured in the software to enable the pull up resistors. This means that the by default they read a 
a high (1) and go low (0) when pressed. 


As you can see there are plenty of pins available to add additional controls. 


Software 


A sketch is the name that Arduino uses for a program. It's the unit of code that is uploaded to and 
run on an Arduino board. There is an IDE that is used to write the code, compile and upload to the 
device. A sketch always contains at least 2 functions, setup and loop. 


void setup() { 
} 


void loop() { 
} 


The code in the setup function is executed when the device is powered up or reset. 
The code in the loop function is then run continually repeating the code. 


A simple sketch to configure the USB serial port to run at 9600,N,8,1 and to output the state of a 
button connected to digital pin 3 every second is shown below: 


const int buttonPin = 3; 


// setup initializes serial and the button pin 
void setup() 


Serial. begin(9600); 
pinMode(buttonPin, INPUT); 


// loop checks the button pin each time, 
// and will send serial if it is pressed 
void loop() 

{ 


if (digitalRead(buttonPin) == HIGH) 
Serial.write('H'); 

else 
Serial.write('L'); 


delay(1000); 


To save time and effort in development there are libraries available to handle step encoders and 
debounce switches. I have used Encoder and Bounce? as they are easily available online and can be 


loaded into the IDE. These are actually C++ libraries that get compiled along with the sketch. 


#include <Encoder.h> 
#include <Bounce2.h> 


To define an encoder we simply use the constructor and pass in the pins that the clock and data are 
connected to. In this case they are pins 2 and 3 so the code in the library will make use of the 
interrupts available on those lines. 


Encoder tuningEnc(2, 3); 


We then need to define the switches using the debounce library. Note that at this time we do not 
specify the pin as this is done during setup. 


#define encoderPin 4 
Bounce encoderSwitch = Bounce(); 


#define bandPin 5 
Bounce bandSwitch = Bounce(); 


#define modePin 6 
Bounce modeSwitch = Bounce(); 


#define functionPin 7 
Bounce functionSwitch = Bounce(); 


We also need to define some global variables. 


int encoder=0; // 1 while encode switch is being pressed 
int function=0; // 1 while function switch is being pressed 


int afGain 
int rfGain 


-1; 
-1; 


char message[8]; 
int messageIndex=0; 


The gain values are initially set to -1. This lets the code know it needs to request the current value 
using CAT commands. 


When first powered up or reset the setup function is run. This is used to configure the digital input 
pins for the switches and the serial port. 


void setup() { 


// setup function pin 
pinMode(functionPin, INPUT); 
functionSwitch.attach(functionPin) ; 
functionSwitch.interval(20); 
digitalwrite(functionPin, HIGH); 


// setup band pin 
pinMode(bandPin, INPUT); 
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bandSwitch.attach(bandPin) ; 
bandSwitch.interval(20); 
digitalwWrite(bandPin, HIGH); 


// setup mode pin 
pinMode(modePin, INPUT); 
modeSwitch.attach(modePin) ; 
modeSwitch.interval(20); 
digitalwrite(modePin, HIGH); 


//setup encoder switch 
pinMode(encoderPin, INPUT); 
encoderSwitch.attach( encoderPin ); 
encoderSwitch.interval(20); 
digitalwrite(encoderPin, HIGH); 


Serial.begin(9600); 
q 


Once the setup function has been run the loop function is run repeatedly. We need to check the 
status of the switches. One switch is designated as the function switch. When held down it changes 
the function of the other switches. Note that as the switches are connected to ground and the 
internal pull up is enabled then they are indicating a high (1) value when not being pressed and a 
low (0) value when pressed. We process this first before checking the step encoder or other 
switches as its state determines their functionality. The debounce library has a call to show that the 
state has changed, Bounce.update, it returns true if it has changed. 


void loop() { 


if(functionSwitch.update()) { 
if(functionSwitch.read()==0) { 
Function=1; 
} else { 
Function=0; 
} 
i: 


} 


Another of the buttons is used to change the Band Up/Down. It sends the CAT command to step the 
band up to the next band if the function switch is not pressed and sends the CAT command to step 
the band down if it is pressed. 


if(bandSwitch.update()) { 
if (bandSwitch.read()==0) { 
if(function) { 
Serial.print("ZZBD;"); 
} else { 
Serial.print("ZZBU;"); 
} 
} 
} 
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As you can see, it is fairly simple to implement different CAT commands for different switches. 


The tuning control simple sends a CAT command to step the tuning up/down by the current step 
amount as it receives each step change. The control is also used to change the audio gain if the 
function button is pressed or the drive level if the step button is pushed in. 


One problem is that to change the audio gain or drive level the CAT command contains the value 
that it is to be changed to. To facilitate this, the first time the audio gain or drive level is changed, 
the code sees that the current value is -1 so sends a CAT command to retrieve the current value from 
the host software. Subsequent changes just send the new value. Note that we reset the step position 
to 0 each time. This means the value returned is always +1 or -1 depending on the direction. 


long tunePosition = tuningEnc.read(); 
if (tunePosition != 0) { 
tuningEnc.write(0); 
if(function) { 
if(afGain==-1) { 
Serial.print("ZZAG;"); // get the current audio gain 
} else { 
if(tunePosition<0) { 
afGain--; 
if(afGain<0O) { 
afGain=0; 


} 
} else { 
afGaint+; 
if(afGain>100) { 
afGain=100; 
} 


} 
Serial.print("ZZAG"); // send the audio gain 


Serial.print(afGain/100) ; 
Serial. print((afGain%100)/10); 
Serial. print (afGain%10) ; 
Serial.print(";"); 


} else if(encoder) { 
if(rfGain==-1) { 
Serial.print("ZZPC;"); // get the current drive level 
} else { 
if(tunePosition<0) { 
rfGain--; 
if(rfGain<0) { 
rfGain=0; 


} 
} else { 
rfGain++; 
if(rfGain>100) { 
rfGain=100; 
} 


} 
Serial.print("ZZPC"); // send the drive level 


Serial.print(rfGain/100) ; 
Serial. print((rfGain%100)/10); 
Serial. print(rfGain%10) ; 
Serial.print(";"); 


} 
} else { 
if(tunePosition<0) { 
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Serial.print("ZZSB;"); // tuning step back 
} else { 

Serial.print("ZZSA;"); // tuning step forward 
} 


z. 


The final part of the code is to handle serial data received from the host. This is implemented as a 
function that is called from the loop each time. This reads data 1 byte at a time and builds up the 
command until it sees a semicolon and then decodes the command. 


void checkSerialData() { 
while(Serial.available() > 0) { 
// read the incoming byte: 
char c=Serial.read(); 
DE CCa SE). 
if(strncmp(message, "ZZAG",4)==0 && messageIndex==7) { 
int gain=((message[4]-'0')*100)+ 
((message[5]-'0')*10)+ 
(message[6]-'0'); 
afGain=gain; 
} else if(strncmp(message, "ZZPC",4)==0 && messageIndex==7) { 
int gain=((message[4]-'0')*100)+ 
((message[5]-'0')*10)+ 
(message[6]-'0'); 
rfGain=gain; 
} else if(strncmp(message, "ZZMD",4)==0 && messageIndex==6) { 
int mode=((message[4]-'0')*10)+ 
(message[5]-'0'); 
if(function) { 
mode--; 
if(mode<0) { 
mode=11; 


Bs 
} else { 
mode++; 
if(mode>11) { 
mode=0; 
a 


J 
Serial.print("ZZMD"); 
Serial.print(mode/10); 
Serial.print(mode%10) ; 
Serial.print(";"); 
} else { 
// unhandled message; 


messageIndex=0; 
} else { 
message[messageIndex++ ]=c; 
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Conclusion 


As I have shown it is fairly simple to implement a CAT based controller for HPSDR. I have shown 
how to make a fairly limited, but useful, controller at minimal cost. It is not difficult to add 
additional buttons and step encoders to extend the functionality. 


This prototype has 3 step encoders that are configured for audio gain, drive level and tuning. It also 
has 6 push buttons and a small OLED display. It is also using an Arduino Due for the added 
performance to support the OLED display. 


nits 
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Illustration 6: Prototype controller with more functionality 
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I have successfully used the controllers with openHPSDR PowerSDR, a modified version of 
ghpsdr and a modified version of my Android client with some of the CAT commands implemented. 


Illustration 7: Windows - openHPSDR PowerSDR 


Illustration 8: Linux - ghpsdr 
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Illustration 9: Android - openHPSDR 
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ARDOP (Amateur Radio Digital Open Protocol) 
A next generation digital protocol for HF and VHF/UHF 


Rick M uething KN6KB M atthew Pitts N8OHU John Wiseman GM 8BPQ 


Abstract: 


The popularity of low cost PCs and tablets with substantial DSP processing power and an increasing 
awareness of digital signal processing in the amateur community have created an explosion of digital 
modes. Some of the challenges this poses are lack of portability, inconsistent “virtual TNC” interfaces 
and protocols optimized for single uses. ARDOP is anew protocol development which was targeted to 
address these challenges. The development started in 2014 and Alpha testing of the ARDOP_Win 
TNC (Windows version) was begun in April 2015. From the beginning the protocol was designed to 
cover a wide spectrum of amateur uses and be fully documented with open sourced code to encourage 
learning, experimentation, evolution and portability to other platforms both software and hardware. 

K ey words: ARQ, FEC, 4FSK, 8FSK, 16FSK, 4PSK, 8PSK, WINMOR, cyclic prefix, bandwidth 
negotiation, automatic timing, open source and sound card protocols. 


Introduction: 


Today’s computing platforms (PCs, laptops, tablets and smart phones) pack more numeric processing 
capability than expensive dedicated DSP hardware of just 10 years ago. This with simple low cost 
sound cards/interfaces and modern radios with built in “sound cards” combine to make the setup and 
experimentation of software generated digital modes an important part of our amateur radio hobby. 
These modes range from simple keyboard and weak signal modes such as PSK 31 and]T65 to more 
complex high speed message/file modes with the ability to automatically adapt to changing signal 
strength and propagation conditions. WINM OR [1] developed by one of the authors in 2008 has seen 
good acceptance as a low-cost Pactor alternative in various messaging systems like Winlink 2000 and 
BPQ32. Each generation of protocol and increase in low cost DSP equipment provides an opportunity 
to expand both the performance and flexibility of software controlled digital modes. But the 
development, optimization and support of a full featured digital protocol require a substantial 
contribution of time and skills that should be spread over many applications, operating systems and 
years of use. The development of ARDOP started with a short list of target objectives: 


e Open Design promoting targeting to various computer, OS, and hardware platforms 

e Wide range of bandwidths to optimize spectrum usage 

e Automatic channel adaptability... ability to adjust to changing propagation and S:N 

e Support for both connected ARQ (Automatic Retry reQuest) and multicast FEC (Forward 
Error Correcting) transmission modes. 

e Minimize interference potential (bandwidth negotiation and effective busy channel 
detection) 
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e Flexible operating modes and radios. Compatibility with popular voice grade HF and 
VHF/UHF transceivers using modulation optimized for the frequency of use. 
e Full binary transmission and support for multi-language UTF-8 character sets. 


These expanded over a period of months to first a skeleton specification and finally a full detailed 
specification with detailed spread sheets showing the composition, bandwidth, robustness and speed of 
several modes across a 200 to 2000 Hz (audio bandwidth) spectrum [2]. In deriving the specification 
care was taken to provide avenues to encourage experimentation yet not impact the compatibility of 
compliant implementations. 


Virtual TNC with Host concept 


The experience with hardware TNCs and the portability of virtual (software) TNCs such as WINMOR 
has confirmed the benefit and flexibility of separating the “TNC” or modem function from the host 
(user) application. This promotes portability and allows the same TNC code or hardware 
implementation to be used (without change) in a variety of diverse applications such as keyboard 
clients, messaging systems, tracking functions, sounding systems, emergency beacons, etc. We chose 
this path to allow us to focus first on the protocol and TNC and not the final user host application. To 
the user the virtual ARDOP TNC operates similar to a hardware TNC and like a hardware TNC can 
display operating parameters or hidden away to avoid clutter. Figure 1 is an example of the ARDOP 
Win TNC showing asmall but rich panel to display operating parameters, transmission progress and 
for the entertainment of the operator! 


ARDOP Win Virtual TNC 


File Graphics Send Abort Logs Help 
Rev Level: Offset: -1.3Hz State: DISC 
om : he: : Hoy Pane 2 
BPSK.200.100,E 
Xmt Frame: 
BPSK Quality. 71 ~1200 CF-1500Hz Fi Fos: TCPIP 


Fig 1. Screen capture of the ARDOP_Win TNC user interface/display 


The virtual TNC can interface to the host program via a TCPIP connection (wired or wireless), a high 
speed serial connection or a wireless Bluetooth connection. This permits not only flexibility but the 
ability to operate the TNC/Radio combination remotely from the host software. Likewise a hardware 
implementation of the protocol (e.g. PIC microprocessor with sound card chip) could interface to the 
same host software and provide functional equivalence and compatibility. A simplified block Diagram 
of the ARDOP TNC is shown in Figure 2. 
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| ARDOP TNC Simplified Block Diagram 


SFSK_ BFSK, S6FSK 
SPSK, BPSK 


Heuristic Gear shifting FEC and ARQ 
200-2000 Hz, mPSK, 4PSK, BPSK Protocol 
100, 167, 600, 1000 baud 


Receive Mixer 


Modulator 
FEC Encoder Sates ‘tos Transmit Filters ie. Sound Card 
Reed Solomo Playback Device 


200, 500, 1000, 2000 #2) 


Channel 
Busy Detecto 


FEC Decoder Goertzel Sound Card 


(Reed Solomon Demodulator and Filters Capture Device 
Carrier Buffering nFSK, 4PSK, BPSK 


And Averaging 
Symbol & frame Leader Detectot | User interface 
Sync and tracking And DSP Tuning 
Boca 


Fig 2. ARDOP TNC Simplified Block Diagram 


ARDOP Performance 


M ost amateurs familiar with digital modes are aware of the tradeoffs required when it comes to 
robustness, bandwidth, signal strength and propagation quality. Some specialized modes can work 
deep into the negative S:N regions but they are very slow... Sometimes exchanging only call signs. 
High speed modes permit sending large files and images but need fairly good signals, wider 
bandwidths and minimal multipath propagation or path compensation. Even within a 10 minute QSO 
or forwarding session wide variations in signal strength and propagation quality are often observed. 
One solution to this problem is for the sending station to adjust modulation type and bandwidth based 
on the current propagation channel. ARDOP uses a simple but effective mechanism to send the 
received decode quality (basically a “score” of the last received frame’s symbol constellation) back to 
the sending station with every ACK or NAK. During the development of ARDOP aHF channel 
simulator was often employed to develop the modes, mechanisms and optimum FEC level to allow the 
sending station to rapidly home in and maintain near optimum modulation (and bandwidth in some 
cases). This allows the session to proceed with the highest data rate that can be supported with the 
current S:N, propagation channel and bandwidth. Figure 3 shows two typical net throughput 
measurements (200 Hz channel and 2 kHz channel) made during Alpha testing using long ARQ 
sessions on an HF channel simulator across various HF channel types. 
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10000 
seg | MBDOP 200 x BW ARG 6/22/2015 ARDOP 2000Hz BW ARQ 7/3/2015 
800 a g 8000 i 
fsa € Z 
E 600 , é == 5 6000 7 ——— 
Fy meat / —= pp = 4000 } eer 
= 200 ZL é Te % vA MPG 
Zo ey # : 
5 0 5 10 15 é aa 
S:N dB (3 KHz) -10 o o 20 
$:NdB (3 KHz) 


Fig 3. ARDOP performance over WGN (white G aussian noise), M PP(multi-path poor) 
and MPG (multi-path good) channel types for 200 and 2000 Hz bandwidths. 


Future plans include experimenting with “training sequences” and DSP path compensation techniques 
to allow higher performance during poor channel conditions. 


Porting ARDOP to Other languages, OS and Platforms 


Three significant challenges for this project from a programming perspective are as follows: 

1) Porting the code from the initial rapid prototyping language used (Visual Basic NET) to another 
language more readily usable on the various target platforms. 

2) Targeting multiple platforms, such as Linux, Mac OS X, iOS and Android. 

3) Finding alternatives to specialized interfaces (sound card, Internet and I/O) that were used for 
development of previous generations of applications by the same developers. 

An interesting thing happens when you start looking into the various options and taking a hard look at 
the source code. For this project, conversion of the VB.NET code to C#was chosen, as a few of the 
source files were actually very similar to the original C/C++ code that can be found on the Internet 
from hams that developed software a decade or two ago. And while conversion to an alternate 
language may appear difficult the Internet is a good source of free tools to do rough conversions. The 
online code converter from Telerik [3] is the one chosen by one of the designers of ARDOP for this 
purpose. When the code is converted by the online tool, it is quite likely that it's not going to be ready 
to compile; the designer had to do a great deal of hand editing of the results to get it to compile and 
that is compounded by the number of files that interact in subtle ways. It also uncovers a lot of corner 
cases where VB.NET specific functionality has to be removed for a more workable product. This also 
provides an opportunity to lay the ground work for the second and third challenges; targeting multiple 
platforms and alternative interfaces. 


When targeting multiple platforms, it is often best to understand the way each one handles user 
specific files such as application configuration files. It is also good to Know what options exist for 
handling the interface to the sound hardware in the device the application will be running on. In the 
past, and this is often still done by application authors, configuration files have been placed in the same 
directory as the application executable is. This is fine in a single user environment, but not when 
installed on a multiuser system. The proper procedure is to place the configuration files in a folder 
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(also called a subdirectory) in the user's home directory. Global files with basic parameter values can 
be installed as well, if desired. A udio device detection can be handled one of two ways; with a custom 
library that is used by the software on the alternative platforms instead of the default library, or one 
that is available on all target platforms. 


Typical Host programs 


For initial on-air testing of the ARDOP protocol we needed a fairly simple host program where users 
could send beacons, basic keyboard text, and small files with ARDOPs FEC and ARQ modes 
exercising various bandwidths and modulation modes. Existing code from a prior project (V 4C hat) 
was modified to interface to the virtual a = — : 
as modified to interface to the virtua » RTT aa 5 ae 
ARDOP TNC using a robust TCP |P . — 
: : : File > Mode; ARQ » ARQ + Abort Logs User Files ~ Queue Data 
interface. Fig 5 shows the basic ARDOP 
Chat host that provided setup for the Se et ari 
A RDOP TN Gi keyboard interaction, “= ARO Call ta WIAW (Bandwidth = 500MAX) @ 2015/08/03 13:43:55 
received data display and file editing and ™* ARDOP_Win TNC STATUS: CONNECT TO W1AW FAILED! 
transmission along with a few 
conveniences like A DIF logging, beacon Fi Joha. 
setup, and basic radio control (PTT and aia Ate 
Frequency). 


== ARQ Call ta GM8BPO (Bandwidth = 500MAX) @ 2015/08/03 134548 


Fig 5. Basic ARDOP Chat host program used for initial keyboard testing. 


Following initial debugging of the ARDOP Virtual TNC and ARDOP_Chat host programs J ohn 
Wiseman GM 8B PQ adapted his BPQ32 [4] host program to interface to the ARDOP Win TNC. This 
allowed additional functions including radio email and binary file transmission through the WL 2K 
system using the existing B 2 forwarding protocol. The following diagram shows how the BPQ Host 
interfaces to the ARDOP TNC along with conventional Packet and Pactor hardware TNCs. 


This interface approach (separating the TNC DSP code from the host and interfacing through standard 
TCPIP , Serial or Bluetooth interfaces) allows the TNC code to be host application independent similar 
to the way a typical hardware TNC is. 
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Radio Interfaces 


Packet TNC 


Serial Link Senial Link TCP Link Internet Link 


Data Switch 


Chat Server 


BPQ32 System 
Fig 6. ARDOP Virtual TNC Interface to the BPQ 32 System 


Figure 7 shows a basic screen capture of an ARDOP B2F protocol session with the BPQ32 ARDOP 
TNC interfaced as described in Fig 6 above. 
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Fig 7. BPQ32 ARDOP ARQ session showing the interface to 
the WL 2K Ham radio email system. 
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Project Status 


The ARDOP project began B eta testing using both the ARDOP_Chat and BPQ 32 host programs in 
July 2015. The ARDOP Protocol spec is complete and the ARDOP virtual TNC is operational on both 
the Windows (Win XP- Win 10 using DirectX ) and Linux (x86-Debian and ARM -Raspbian systems 
using MONO and the ALSA sound library) platforms and on A pple using the popular dual boot 
systems. A wide range of data modes covering speed and robustness ranges in excess of 40:1 are 
optimized for both HF (baud rate < 200 baud) and VHF/UHF FM (baud rate > 600 baud) are 
operational. As the B eta phase completes we will release the open source code along with a detailed 
testing and conformance document to allow those adapting or extending the protocol to insure basic 
compatibility with prior implementations. We have also initiated an effort to develop small low-cost 
hardware to allow wireless interfacing (Wi-Fi and Bluetooth) of small computing platforms (tablets, 
smart phones) to HF and VHF/UHF radios that would use the ARDOP protocol. 
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An OS Independent and Device-Independent M obile Web Front 
Panel for R adio Transceivers 


Bruce Perens, Algoram 
bruce@ perens.com 


Introduction 


a 


Algoram has produced a radio front 
panel that runs on almost all popular 
computer platforms, with only iOS 
as the exception at this time. This 
program is not ported from one 
system to another, the exact same 
code runs on every platform. It runs 
well on smartphones. The radio 


> 2 
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1. perengeon 
ertiay Stat rest A) RADIO Re 6? ALGOIRAM Kan fA WVIDIa Regie 
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Brequeacy 145 623 MHz Ser 


includes a WiFi access point and aesde [tiie 


Tastrnetions 


uses this means to communicate 
with the smartphone. Bluetooth can 
also be used. 


Put thee carson ower thee waterfall (oe touct i een tablet uy pitiecne) tie tne 


The computing resources required in 
the radio to support this system are 
very modest and run in inexpensive 
microprocessors without virtual 
memory support. The smartphone interface includes a waterfall bandscope and can support all manner 
of graphical displays and controls. The smartphone user interface doesn't require much dexterity and 
can be easily used by most people. Tablets of various sizes are also supported and provide additional 
display area and ease-of-use. 


Illustration 1: A test of Algoram's waterfall bandscope using random data. 
Image is copyrighted by the author and released under the same terms as this paper. 


This front panel is part of Algoram Katena, a 50-1000 M Hz software-defined HT which can be 
programmed to communicate using many different modulations, modes, and protocols. We've 
previously refered to Katena as “Whitebox” or “HT of the Future.” 


K atena is a front-panel-less HT which remains in the user's pocket or on a belt, and is controlled with a 
smartphone, with the smartphone providing the audio input and output as well as all front-panel 
functions. Currently this exists as a prototype larger than an HT, which will be made available in base 
and mobile form factors first, and then will be further miniaturized to become a handheld device. 


The key to this technology has been the use of emerging HTML5 APIs to run our software in the 
device's web browser. There have been previous efforts that provided receiver interfaces, with 
bandscopes, using some form of HTML or perhaps J ava. Recently, browsers have gained standardized 
APIs for two-way audio and video communications, and thus they make the microphone and camera 
available to the program. They were already capable of providing all manner of 2-D displays, audio 
output, and controls needed to operate a radio. 
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Revenge of the Clones 


Computing hardware and operating systems are fragmentary, they aren't all the 
same and they don't all run the same code, and this is in general a benefit to 
society. Imagine if Operating Systems were like the 
“clone army” in Star Wars episodes I! and III. J ust 
as clone troopers would all be “identical-twin 
brothers” who share the same DNA, Operating 
Systems could all look the same and run the same 
code. Wouldn't that be great? 


No. When one clone trooper got sick, they'd 
probably all get sick. And here's a real-world 


Illustration 3: A Tasmanian Devil 
afflicted with contagious cancer. 


Illustration 2: A 


cosplayer acting asthe example: because Tasmanian Devils became so Image by Menna J ones from a PLoS paper 
tar Wars clon n : u ” under a Creative Commons Attribution 
= arty e] ange inbred that they are clones from an license, see https://commons.wikimedia.org 


immunological perspective, they have developed wiki/F ile: Tasmanian_D evil_F acial_Tumour 
_Disease.png for details. 


This image was created by Sam ' F ae 
Howzit and is under Creative a CONtagious cancer that is driving them to 
Commons Attribution 2.0 : : ee : : 

license. The name and image of CXtl nction. Cancer isn't contagious In people 
Jango Fett are trademarked by because we aren't clones and we each have 
Disney and their use here is ‘ : 

intended to fall under the Fair Gifferent immune systems. 

Use doctrine. Downloaded 


from https://commons. Similarly, different software doesn't fall victim 
wikimedia.org/wiki/F ile:} ango F : 
_Fett,jpg to the same viruses and security bugs at the 


same time, and thus a network of hetrogenous 
systems (ones different from each other) is more likely to have some 
portion continue to operate during an attack, while a network of 
homogenous systems (all the same) is likely to have all of its nodes 
fail. 


Fifteen years ago, when the Microsoft Windows systems at the 
largest global express delivery company were attacked by the Red 

F lag virus, their entire global computer network went out of service 
and their hundreds of thousands of employees had to operate on Illustration 4: "The Scream" by Edward 
phones and fax machines for a day, until of the Windows systems Munch, has frequently been used to 
could be brought down and disinfected. Only a few systems running illustrate frustration with computer 


aint failures, although M unch did not live in 
the BSD operating system maintained the company's web presence. she Compuiernae: Covirinniobirel 


So, What Does This Have To Do With Ham Radio? 


Hams operate the emergency services communication network of last resort. We are building more 
computers into our systems because that's the way that technology is heading, and we are creating 
digital networks that allow our computers to exchange data over the air, and thus make it possible for 
them to exchange viruses and manifest security bugs over the air. Thus, in order for our systems to be 
effective during emergencies, they must not all run the same software. 
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The Heartbreak of Hetrogeny 


So, we've established that having hetrogenous systems, which don't all run the same code, are 
important for the security and continued operations of the world's computer networks, and are even 
more important to the radio amateurs who operate the network of last resort. But there is also a great 
cost to hetrogenous systems. B ecause they will not, in general, run the same code, we will often have 
to build separate programs to perform the same task on each different flavor of system. 


Thus, anative application for an operating system, one which directly uses the CPU and its instruction 
set, the GUI, and the operating system services for that system, will be different from a native program 
on another OS or even a different hardware device. Native programs for M icrosoft Windows and 
MacOS will in general look very different at the source-code level, and programs that look the same at 
the source code level will have to be recompiled for differing instruction sets, for example those on the 
the Intel CPUs common to desktops and theA RM CPUs common to smartphones. 


So, we end up with a vast combinatorial problem. Even a company that can employ many 
programmers will find it difficult to economically support all of the available hardware and operating 
system combinations. 


Software engineers have tried to solve this problem by making programs more portable, which means 
giving them the capability to be used on more than one kind of system. There have been many different 
approaches to solve this problem: 


e WehaveApple and Microsoft, who each would really prefer that everyone in the world run 
their systems so that there'd only be one kind of OS to program for and portability would not be 
an issue. But this brings us back to the “clone army” problem. 


e Wehave portability layers like wxWidgets and Qt, which attempt to hide differences between 
systems at the source-code level, at the cost of an increase in program size and resource use, 
and the failure to include all native GUI and operating system facilities in its A PI. 


e Wehave] ava, which tries to hide the CPU, operating system, and GUI and run the same 
programs everywhere. This hasn't worked out as well as the J ava designers would have liked, 
for example there is a different GUI on Android smartphones and desktops, even though both 
run J ava, and because of differences in] ava implementations “run everywhere” tends to have 
also meant “test every possible system”. Solving the performance issues of J] ava has taken the 
development of just-in-time-compilers, which turn J ava into native code. These are large and 
consume their own resources. 


e We have software-as-a-service, which runs the program on a server somewhere on the web, and 
provides it to the user via a web browser interface. This has the benefit of removing the need 
for users to administer servers and the programs that run on them, but it has tended to fail in a 
disaster, as the server is in general far away and must be accessed via a high-speed Internet 
connection. In a disaster, Internet access is likely to be interrupted. 


Software-as-a-service can also have the effect of transmitting a service interruption far beyond the 
physical boundaries of a natural disaster. Hurricane Sandy took many data centers down, effecting 
software-as-a-Service customers worldwide because not every service provider had, or could afford, 
fail-over mechanisms outside of the disaster area, which spanned several U.S. States. 
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e Wehave computer languages, many different kinds, which in general hide the differences 
between CPU instruction sets but not operating systems or GUIs. For example, the C language 
is available on very many different CPUs, and once you have aC compiler, you can use it to 
build the facilities of many other languages, for example Python and J ava. 


A New Hope 


The web started out as a very simple way of displaying pages with links to other pages, but it didn't 
stay that way for long. The needs of providing additional interactivity, mostly to support software-as-a- 
service, inspired the implementation of J avascript (a different thing from | ava) and the addition of 
many new APIs, and this continues to the present day. 


On the one hand, this means that web 
programming is architecturally messier, HTN 
and more difficult, than if the whole : aie 
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time. Web programming now requires 
the use of at least three separate 
computing languages, HTML, 

} avaScript, and CSS, for the portion of a 
program that runs in a web browser, 
often a fourth language is used to 
implement the server-side software, and 
there can be even more languages 
involved, for example SVG which is 
used to define resolution-independent 
vector images, and M athM L to format 


mathematical equations. There are also Illustration 5: HTML5 and related APIs. This image was created by Sergey 


' Mavrody and is under the Creative Commons Attribution Share-Alike 3.0 Unported license. 
dozens of APIs to learn, as shown in the ¢.2'htips:j/en.wikipedia.org/wiki/HTM L5#media/File:HTML5_ APIs. and related. 
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facilities, web browsers have gotten 
huge, and use substantial resources. 
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On the other hand, the web browsers that closely track the HTML5 standards process, Google's 
Chrome, the M ozilla Foundation's Firefox, and Opera Software's eponymous browser, are now capable 
of all operations that we would want from a radio control panel. M ost importantly, they handle two- 
way audio and video, 2-D graphics sufficient for radio controls and displays, and efficient network 
communications. T hese three browsers run on very many systems, and all three will run the same 
program. Each browser is itself built from a different code base, although some code is common to two 
of the three. So, there is some protection from bugs effecting all three browsers, although bugs in the 
user's program could be exploited on all three platforms. 


The Party Pooper 


Chrome, Firefox, and Opera aren't the only popular web browsers. There is Safari, which is available 
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in different versions on Mac OS X and iOS. DespiteA pple's greater expense relative to other products 
and a corps of users who are perhaps fanatically dedicated to A pple and its products, A pple hasn't kept 
up and isn't capable of running all of the audio APIs necessary for a radio front panel without the 
creation of an iO S-specific application to support those facilities. To make the situation worse, Apple 
has a policy of handicapping competing browsers which it accepts for its A pp Store by insisting that 
they run Apple's own web rendering software rather than the browser developer's usual software. This 
means that Chrome on iOS is just as crippled by A pple's failure to keep up as Safari on iOS. This 
unfortunate policy doesn't exist for Mac OS X: Chrome, Firefox, and Opera are fully functional on that 
platform. 

At this writing, itis not known at present if A pple will provide the necessary A Pls on its upcoming 10S 
9. Itis expected that A pple will eventually provide them, but this could be years in the future. 


Microsoft's Internet Explorer tends to have inconsistent or behind-the-times implementation of new 
web standards, however Chrome, O pera, and Firefox all run well on Microsoft platforms. 


So, What Platforms Can We Support With HTMLS Front Panels? 


At present, our HTML5 radio front panel can run on these platforms. The exact same code base runs 
on all of them: 

e Microsoft Windows systems running Chrome, Firefox, or Opera. 

e MacOS X systems running Chrome, Firefox, or Opera. 

e Android smartphones and tablets running Chrome, Firefox, or Opera. 


e Linux systems running Chrome, Firefox, or Opera. This includes essentially all Linux 
distributions, for example U buntu, Red Hat, Debian, and Centos, but does not include ucLinux, 
which does not provide virtual memory. However, our server-side software runs on ucLinux. 


e Chromebooks and ChromeOS. 


e Kindle Fire HD 7, but only when you install Chrome using the sideload process rather than 
Amazon's app store. 


These probably work too, or can be made to work, because they support the necessary browsers. But 
we've not tested them: 


e Other Kindle tablets with non-e-paper displays and current OS software and the Fire phone, but 
only when you install Chrome, Firefox, or O pera using the sideload process rather than 
Amazon's app store. 


e TheBSD operating system running Chrome, Firefox, or Opera 
e Firefox OS and the Firefox phone. 
e Ubuntu's phone platform. 
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What Doesn't Work, Then? 
This leaves us with iOS as the only hold-out among popular computing platforms! 


And of course we could write an app for iOS, but that would be pandering to A pple's bad policies. 
We'll wait for them to catch up with web A Pls. 


Can We Support Even More? 


Set-top boxes and TV dongles, and the various runners-up in the smartphone and tablet market: for 
example Microsoft's phone platform, Symbian, Blackberry, and WebOS might support, or might be 
persuaded to run, a browser with the required A Pls. Android A Pls are supported by some set-top boxes 
and TV dongles, and Android programs that are not directly available in the device's app store can 
often be sideloaded onto the device. We did sideload Chrome onto the K indle Fire. This circumvented 
the artificial limitations of Amazon's app store, which declined to offer Chrome for the device in favor 
of Amazon's less-functional Silk browser. 


The Operating System 


Our current hardware runs ucLiunux, a compact version of the Linux operating system that runs on 
devices without virtual memory. We run iton an ARM Cortex M3 CPU within the SmartF usion II chip, 
which contains our gate-array on the same die. Our CPU is a single-core 200 M Hz processor, and can 
yet support a significant server, WiFi, Bluetooth, Ethernet, |PV 4, both USB master and slave, and 
FLASH storage. So, we have a capable server that will fit in your pocket with the radio. 


Our software is actually a form of software-as-a-service, but with the server in your pocket! Thus, 
there aren't the disaster-fragility problems of the usual software-as-a-service implementations. Our 
server remains up on battery power and communicating with local devices via WiFi and distant devices 
viaA mateur Radio, regardless of the state of infrastructure around it. 


It is expected that later devices will eventually run the full Linux system on virtual memory hardware, 
rather than ucLinux. The selection of Cortex M 3 rather than a larger CPU is due to our use of 

SmartF usion I|, which provides a FLASH -based gate-array which is capable of using battery power 
efficiently. The smilar|gloo || gate-array which does not provide a CPU costs as much as the 

SmartF usion I], so we essentially get the CPU for free! 


The Web Communications APIs 


At first, WebRTC appeared to be a desirable means of communicating between a browser and a radio. 
It's designed for audio and video telephony as well as data communications, and includes “NAT 
traversal” which solves problems with calls to systems on home networks from the outside. It's 
connected directly to the web audio and video APIs, and automatically scales the data compression and 
codecs used to make the best use of the available bandwidth. 


What WebRTC lacked was a small, Open Source, embedded library that could serve it to a browser 
client. Our software is Open Source, and we in general prefer to use Open Source both for economic 
and collaboration reasons and because we can fix its bugs if necessary. The only Open Source software 
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stack available to us used a very substantial portion of the Google Chrome browser code. That was 
overcomplicated and would not fit in our device. 


With that determined, we switched to Websocket, a much simpler web API for creating a data stream 
between a browser and another program. On the browser side, Websocket was easy to program in 
Javascript, requiring only a few lines of code to handle the connection. 


On the server side, we made use of libwebsockets, a compact Open Source embedded library in the C 
language. This worked, and fit well in our low-resource CPU running ucLinux. Unfortunately 
libwebsockets was not as mature as we would have liked, and has required some debugging of its 
internals in order for it to work correctly in our application. This work was contributed back to the 
project. Since our company benefits from the work of thousands of Open Source programmers, it's 
only fair for us to join in that work on existing programs like libwebsockets, as well as to contribute 
our own new software. 


The Web GUI APIs 


The web GUI is built using the HTML5 Canvas object, and its 2-D drawing environment. This 
provides a] avascriptA PI for drawing and animating all sorts of 2-D displays, buttons, and knobs, 
using an imaging model descended from A dobe's P ostScript. Canvas also supports a 3-D API which 
we have not made use of yet. 


Input comes from the keyboard, mouse, or touchscreen, and multi-touch is used to change the 
bandwidth of the waterfall display using a “pinch” gesture in which two fingers are used to stretch or 
compress the display. 


Where a keyboard is available, the space bar is = 
used for push-to-talk. On touchscreen deviceswe 9 

do not use push-to-talk, but a separate transmit el 

and receive button. This works very well on _— ALGORAM Katena Developer Board 
smartphones. It's awkward to hold down a screen = Wik a. ' Status: Feectnag, LOOP late awe of etwerk ach pocket 
device in the way we are accustomed to holdinga \.* 4 ss 

push-to-talk button on an HT, especially when KS Transmit Receive 

using a smartphone. However, there is an input . 
for a push-to-talk switch on the radio, and we can 


" 


Frequency 


make a PTT switch available viaa USB or ALGORAM sisters 
Bluetooth peripheral. We have programmed @ tims st teapot mm enirkon’ ir tnmmtns oy wo 
library to make use of USB and Bluetooth Illustration 6: A test of web push-to-talk. 


“i : ‘ ; Image copyrighted by the author and released under the same terms as this 
human- interface devices, and Various USB dials (272, 
and pedals have been tested. 


Web Audio 


The Web Audio API is an interesting creature, providing a graph of many different audio processing 
nodes that can be connected to each other, including compression, gain, frequency equalization, and 
even a node that runs a Fast Fourier Transform. It includes a means of acquiring the system 
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microphone and loudspeaker and connecting them into this graph. All of this is meant to connect 
directly to WebRTC, which has its own nodes that work in the audio graph. B ecause we use 
Websocket, which has no such nodes, we add to this graph two nodes which process arrays of audio 
samples and network data in J avascript, passing the data between the web audio API and Websocket's 
interface to the network. Fortunately, J avascript is well-enough optimized that this runs well even on 
smartphones, using substantially less than the full CPU resources. 


A complication of the web audio API is that it does not allow the user to select a sampling rate, but 
imposes its own, and this rate differs between platforms! Thus, a simple interpolation was programmed 
in Javascript, and is used for both audio input and output, while the audio sample rate used for network 
communications is set by the program. This works sufficiently well and there is still lots of CPU left, 
even on a smartphone. 


Another complication is that Websocket does not have access to the same means of compression that 
would be used with WebRTC. At present we solve this by simply sending and receiving 16-bit data at 
8K samples-per-second, a bandwidth that works well on Bluetooth, WiFi, and internet connections. It 
would be possible, although perhaps awkward, to program entire codecs in J avascript. There have been 
several efforts to define and implement a subset of javascript with high efficiency, which would be 
appropriate for codec programming. 


Putting It All Together 


Using all of theseA Pls, we have created a complete radio front panel as two programs: a client 
program that runs in the browser, and is coded in J avascript, HTML, and CSS, and a server program 
that runs in our radio device, coded in C++. The server program stores the client program on the radio, 
and sends it to the browser when the browser connects to the radio. 


It would be awkward if it was necessary to type in a URL to connect to the radio. Indeed, the various 
controls of the browser aren't really necessary for our radio front panel, and our screen would be neater 
if we could get rid of the URL bar and the browser menus, buttons, and tabs. Fortunately, we can! 
There is an evolving standard for packaging web programs as A pps, which allows them to be started by 
touching an icon like a conventional app, and to run in full-screen mode without any of the usual 
browser controls visible, only the controls in our own program. Once packaged this way, web 
programs become indistinguishable from apps. They can be installed from an app store, or can be sent 
to a smartphone by our radio for direct installation. 


Security 


Obviously, we must not allow unauthorized individuals to control our transmitters using web 
interfaces. Fortunately, we have the entire set of security facilities used for other web applications: 
encrypted network connections over WiFi or Bluetooth, logins and passwords, etc. B ut this is just the 
Start... 


Authenticating Using Logbook of the World Certificates 
Inspired by a paper at the TAPR conference by Heikki Hannikainen OH 7LZB, and by the work of 
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ARRL's Logbook of the World designers, we have implemented a means for our radio to authenticate 
strangers on the internet as licensed radio amateurs who are allowed to control a transmitter. 
Individuals who have been set up by ARRL to use Logbook of the World are each sent a file containing 
a x.509 public-key encryption certificate. We have instructions on how to export these certificates from 
LoTW and load them into a web browser. Once an A mateur has done this, the browser will 
cryptographically authenticate itself to our radio, communicating the amateur's identity and callsign 
securely. 


Thus, an Amateur can make the Algoram K atena radio available as a public facility on the internet, to 
be used by Amateurs from all countries, and can be assured that only licensed A mateurs will be 
allowed to connect to the radio. Since the software gives us the A mateur's call sign, it would be 
possible to implement a means to automatically determine what privileges an A mateur of a particular 
nation and license class should be granted when operating a transmitter in another nation remotely, and 
to disallow operation on unauthorized frequencies and modes. 


In Summary 


Obviously, these are features that have never existed in a walkie-talkie, and have only been partially 
attempted on a few experimental base stations. So, this is going to be a whole new world for A mateur 
Radio. The rest of our hardware and software design is equally innovative, and will be presented in 
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Introduction 


What is Broadband-Hamnet™ ? 


The Broadband-Hamnet website (http://www.broadband-hamnet.org) describes the system as the 
following: 


“Broadband-Hamnet™ (formerly called HSMM-Mesh™) is a high speed, self discovering, self configuring, 
fault tolerant, wireless computer network that can run for days from a fully charged car battery, or 
indefinitely with the addition of a modest solar array or other supplemental power source. The focus is 
on emergency communications. 


In its current form it is built using the Linksys WRT54G/GL/GS wireless routers and operates on channels 
1-6 of the 2.4GHz ISM band, which overlaps with the upper portion of the 13cm amateur radio band. 
Other platforms and bands include several types of Ubiquiti equipment in the 9OOMHz, 2.4GHz and 
5.7GHz band. Additional features let signals come in on one band and leave on another without 
additional configuration. All mesh nodes on all bands exchange data so long as they are within range. 
We will be adding support for Ubiquiti 3.4GHz gear as well.” 


What is Amateur Radio? 


Amateur Radio is a “service” as defined by the Federal Communications Commission. Also called Ham 
Radio, the service is a hobby, public service, and a method of emergency communications. Operators 
must be licensed through an examination process by the FCC. The FCC has granted amateur licensees 
use of different parts of the radio frequency (RF) spectrum ranging from 1.8 MHz to 275 GHz and 
beyond. 


As a hobby, operators can communicate with each other on allocated frequencies both locally and 
internationally. Operators often try to contact others in as many counties, states, countries, or 
continents as they can. Methods can include voice, Morse code, and text-based modes. 


As a public service, operators provide, free of compensation, communications for countless events 
across the country. Examples include bikeathons, marathons, charity walks, rowing events, car races, 
and countless others. Many of these events are held in areas where cellular phone service may be 
unreliable or nonexistent. Amateur radio is able to overcome this obstacle with ease. 


As a method of emergency communications, amateur radio truly shows its mite. Many disasters disrupt 
conventional communication methods. Phone lines can go down, cellular networks can be 
overwhelmed, and power utilities can go down. Even police and fire radio systems can fail. What 
happens when a police or fire radio tower collapses? Amateur operators are ready and willing to step in 
regardless of the nature and severity of the emergency. 


SSS = 
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Capabilities of the Broadband-Hamnet 


Science of 2.4 GHz 


Broadband-Hamnet devices are typically used in the 2.4 GHz spectrum. This is because of the overlap of 
IEEE 802.11g wireless networks with an amateur radio allocation in the 13cm band. There are some 
considerations that have to be made when using this spectrum, though. First and foremost is the 
propagation of a signal at these frequencies. Unlike HF (3-30 MHz) signals, signals at 2.4 GHz, at the 
upper part of UHF (300 MHz to 3 GHz), cannot refract off of the Earth’s ionosphere and travel long 
distances. As a direct result, the practical range of these devices is only up to about 30 miles in open 
space with no obstructions. However, this cannot be accomplished with stock equipment or without a 
tower. Standard WiFi antennas will only present up to a 6 dBi gain. Using specialized ‘yagi’ or parabolic 
dish antennas, a gain up to 23 dBi can easily be achieved. Using this model, a point-to-point link of two 
radio towers 30 miles apart with no obstructions and a perfect line-of-site can be achieved. A simple leaf 
on a tree can interrupt a signal at this frequency, so planning and calculation is a must. 


Uses for Broadband-Hamnet™ 


A Broadband-Hamnet system is capable of countless uses for both everyday use and emergency use. 
The beauty of the BBHN system is that it is 100% internet, cellular, and telephone independent. These 
three systems have been known to be unreliable in major disasters. Since the BBHN is based on 
OpenWRT software, it supports any TCP/IP device. Here are a few examples of devices and services that 
can be networked over BBHN: 


e Computers 

e = 6Servers 

e VOIP phones 

e Radio Repeater Linking 
e IP Cameras 

e Weather Stations 


The system is capable of up to 54 Mbps bandwidth, so it is capable of handling most services that are 
needed, even live video. 


Emergency Use 


In anew modern era, even our emergency response requires a constant and stable stream of 
information. This presents many concerns to first responders. Their work is often one-sided, get in, get 
the job done, get out. In an era following disasters like 9/11, Hurricane Katrina, Superstorm Sandy, and 
many other disasters, we have learned that a proper and accurate response requires the availability of 
information. Using the recent and continuing events in Nepal as an example we can discuss some of the 
ways BBHN could be used in a critical emergency. Now close to three weeks after the initial earthquake, 
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internet and phone service is still unreliable. Search and rescue groups such as the Red Cross have 
massive databases with information on thousands of people. How does one access this information 
when existing infrastructure is down? A BBHN node consumes minimal amounts of power and can be 
effectively powered for a week on battery or indefinitely using solar panels. Why would response teams 
want to depend on an already-crippled infrastructure to transport such critical information? Let’s look at 
another use — video surveillance. In disaster zones, medical facilities and food distribution are key to the 
mission of the area. The BBHN system can be used to serve video surveillance, monitoring the security 
of these locations and the accurate operation of these facilities. 


Known Implementations 


Through further research on this awesome system, it was discovered that it is widely used across the US 
and Europe. Most of these systems are used for the services discussed above. Below are just a few of 
few known implementations in the US. Dozens more exist around the world, but many are not 
publicized. 


Heart O’ Texas Amateur Radio Club (HOTARC) — HOTARC maintains one of the largest known mesh 
networks using BBHN. The mesh covers Waco, Texas and some surrounding towns. This system has also 
served as a development platform for BBHN for a number of years. 


Phoenix HSMM-MESH - This is a mesh in the Phoenix, Arizona area. This group is comprised of hobbyists 
and is not affiliated with any groups. 


RI Mesh — This mesh is appears to also be unaffiliated. The mesh is centered around Providence and 
Pawtucket, Rhode Island. 


Hands-On With Broadband-Hamnet 


| spent a couple months working hands-on with Broadband-Hamnet and have documented my findings. 


BBHN is extremely easy to use for anyone familiar with setting up wireless routers. | found that it takes 
about 10 minutes to get a node up and running. This includes flashing the firmware and configuring the 
settings as your mesh requires. The BBHN team has really great step-by-step instructions on how to get 
up and running. It’s a very powerful system designed for use by the average person. 


After getting 2 nodes configured and connected, | wanted to be able to assess their capabilities using a 
system that many BBHN meshes already use — Voice Over IP (VoIP). | setup a Raspberry Pi computer 
with an Asterisk phone server in order to get things rolling. Below is a graphic demonstrating the 
implementation. 
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| was concerned that the VoIP phone adapters would not be able to easily communicate with the server 
due to DNS difficulties, but there were zero problems with DNS or DHCP in BBHN. Again, this reinforces 
that this system is designed for the common person. 


Next was voice quality, how would these calls sound? Would they sound like the other caller is in the 
same room or would it sound like a 1990s analog cellular phone in a tunnel? | was stunned with the 
quality and stability of the call. It was crystal clear. As long as the bandwidth is available and a good path 
can be made between the nodes, there should be no concerns with call quality. 


Unfortunately, | did not have the capability to scale this test up using tower sites and greater distances. | 
was able to conduct a test with a 110 foot line-of-site. Again, | experienced great call quality. It’s no 
wonder that so many mesh users like to use VoIP. 


Continuing Work With Broadband-Hamnet 


The conclusion of this course will not conclude my work with Broadband-Hamnet. | plan on continuing 
my study on the subject for the benefit of the amateur radio community. This will include a real-life 
implementation and a number of community publications. | strongly believe that the community can 
benefit from this system and improve our emergency communications capabilities. 
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The Future of Broadband-Hamnet 


Citing current news from the BBHN website, the future of the system will be slightly altered. Recently, 
Linksys (a division of Cisco), announced the end of support for their WRT router series. These are the 
routers that BBHN was originally based on. BBHN support for these devices will not evolve beyond the 
current version. Future versions will only be supported by Ubiquity WiFi and mesh devices. 


Updates will also only be released every 6 months. The reasoning for this comes from how BBHN works. 
Every node has to be on the same version of firmware in order to communicate. In order to have an 
emergency-ready, rapid deployment system, the need for updating should be limited as much as 
possible. 


In the end, these devices are actually more inexpensive to implement and are designed specifically for 
outdoor installations. Instead of installers having to purchase cabling and an antenna, the Ubiquity 
devices are fully integrated and simplify the installation ten-fold. One user on the BBHN forums has 
already conducted a successful 32-mile point to point test with this equipment. | am confident that this 
is going to be a great direction for BBHN. 
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Abstract—Software Defined Radio technology is 
getting more and more popular among amateur 
radio operators and _ hobbyists, as different 
universal SDR hardware devices have become 
available recently. OpenWebRX is a software made 
for those who want to set up remote SDR receivers 
accessible from the web. It has been developed with 
open-source codebase, multi-user access and easy 
setup in mind, to be an alternative to other similar 
projects (WebSDR, ShinySDR, WebRadio, etc.) It 
supports cheap RTL2832U based tuners. Basically 
OpenWebRxX is an on-line communications receiver 
for analog transmissions (AM/FM/SSB/CW), with a 
web UI on which real-time waterfall display is 
available. Users can select a channel within the 
bandwidth of the sampled signal acquired from the 
SDR hardware. The _ selected channel is 
demodulated on the server and the resulting audio 
is streamed to the browser of the user, where it is 
played back. Users can set receiver parameters 
(channel frequency, modulation mode, filter 
bandwidth) independently. The digital signal 
processing functions have been placed in a separate 
library, /ibcsdr, which can also be considered useful 
as a standalone package. It performs the digital 
downconversion, filtering and demodulation tasks 
on the I/Q data. 


Keywords—SDR, 
HTMLS 


RTL-SDR, open-source, 


I. INTRODUCTION 


The speed of digital computing is increasing 
continuously. In addition, in the last years 
reasonably fast A/D and D/A converters have 
become available. It has become feasible to 
implement most of the signal processing digitally 
in radio systems. 
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Nowadays Software Defined Radio is widely 
used in commercial systems from satellite 
communication to mobile telephony, but it mostly 
does its task hidden in the background, replacing 
the conventional analog communications 
equipment. These embedded SDRs are tailored for 
a specific need (for example running a 4G base 
station), producing better results than their analog 
competitors and solving advanced problems at a 
lower price. 


However, there is also a need for universal 
SDR hardware for prototyping, measurements and 
for use in real-world projects. While devices like 
the USRP, HackRF, BladeRF have come to the 
market to support professional and academic users, 
a lot of amateurs have also started to experiment 
with SDR technology, building cheap receivers for 
specific bands. When the RTL-SDR project [1] has 
been released in 2012, even more people got in 
connection with SDR directly. A mass-produced 
DVB-T receiver USB dongle with an RTL2832U 
chip is a great entry-level device that can be 
acquired for $15, and with the help of the RTL- 
SDR project, it is possible to use it as a general 
purpose SDR. It tunes between 24 MHz and 1700 
MHz, can be used as a receiver for a variety of 
wireless equipment, from two-way radios to 
wireless temperature sensors, and it works on 
multiple amateur radio bands as well. There is a 
vast number of free software available for 
decoding different signals with it. Although its 
professional competitors provide _ better 
performance, it is still an ideal choice for the 
experimenters. 


RTL-SDR is also a great educational tool that 
can help to get more young people into amateur 
radio. For those, who already have the required 
background in IT, playing with the cheap DVB-T 
stick is a great chance to dive into the radio waves. 
I even had a friend under the age of 15 who 
managed to receive the signals of an amateur radio 
satellite with RTL-SDR on his own. 


Two years ago I released an open-source 
project, SDRLab [2], which implements an RTL- 
SDR interface for LabVIEW along with a simple 
WFM demodulator example, and since then, I 
received e-mails from a few university students 
from different countries, asking about it. It turned 
out that at some universities, RTL-SDR is used as 
an educational tool to teach digital signal 
processing. 


So why not bring SDR closer to even more 
people? The motivation behind OpenWebRX was 
to create a remote SDR receiver that is available 
from the Internet, so that amateur radio operators 
can connect to the server with a web browser, click 
on an interesting signal on the waterfall display, 
and listen to the demodulated audio stream, 
without the need of purchasing any dedicated 
hardware to experiment with SDR (as shown on 
Figure 1). 


SDR 


hardware 


USB 


raw 1/Q data 


Internet 
‘spectrum display 
audio stream 


Fig. 1. A high level block diagram of OpenWebRX 


Il. ALTERNATIVES AND DESIGN CONSIDERATIONS 


The idea is not new: there are several software 
available for this purpose. The best known is 
WebSDR, by Pieter-Tjerk de Boer, PA3FWM. 
WebSDR has been developed since 2007, and now 
has numerous great features, like the auto-notch 
filter and the HTMLS mode which also works on 
mobile devices. The drawback is the availability of 


the software: as stated in the WebSDR FAQ, you 
can only get it directly from the author, so it is not 
distributed to anyone by means of free download, 
and the source code is not available at all, so even 
if you have the binaries, you cannot make your 
own modifications. Another good alternative is 
ShinySDR by Kevin Reid, AG6YO, which is 
open-source under the GPL license, but currently 
more suitable for use by only a single person at the 
same time (Kevin noted that multi-user support 
will be available in the future). One more notable 
project is WebRadio by Mike Stirling, which is not 
actively developed at the moment. 


When I started working on OpenWebRX, only 
WebSDR existed as an alternative. I wanted to 
create a software package that implements an SDR 
receiver that satisfies the following requirements: 


¢ it has a web UI (shown on Figure 2), 
¢ it works with RTL-SDR dongles, 


* multiple people can use it at the same time, 
and they can tune to different frequencies 
independent to each other, within the 
receiver bandwidth, 


¢ the source code is available under an open- 
source license, as I consider reviewing, 
modifying and improving ham radio gear 
and software as a good practice. 


OpenWebRX | Open Source Wel-Lased SOR for everyone! - Chramium 


AG 


Fig. 2. A screenshot of the OpenWebRX web UI 
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ll. SETTING UP AN OPENWEBRX SERVER 


To set up an OpenWebRX server at home, you 
will need a computer running Linux, and an RTL- 
SDR dongle. OpenWebRX has been tested on 
Debian/Ubuntu based systems, but it should work 
on other Linux distributions as well. If the 
dependencies have already been installed (rt/-sdr, 
libfftw3-dev, git, python 2.7, gcc, bash), then the 
first step to do is to get the git repositories: 


git clone \ 
https: //github.com/simonyiszk/openwebrx.git 


git clone \ 
https: //github.com/simonyiszk/csdr.git 


Next, /ibcsdr should be compiled: 


cd csdr 

make \ 

sudo make install 

Now OpenWebRX can be started. If it is ran with 
the default settings, it will set the RTL-SDR to the 
2-meter band, and begin acquiring samples. 

cd ../openwebrx 

. /openwebrx.py 

The receiver can be opened in the web browser by 
typing the following URL: 


http://localhost:8073/ 


As OpenWebRX uses some recent HTMLS5 
features that are not present in older browser 
versions, it requires the latest Google Chrome or 
Mozilla Firefox. It should also work on Chrome 
for Android, although it is not optimized for 
mobile devices yet. 


By editing the config_webrx.py file, receiver 
settings can be configured (center frequency, 
sampling rate, gain) and also the details shown on 
the web UI (callsign, location, antenna, etc.) can 
be customized. 


IV. USING OPENWEBRX 


The user interface of OpenWebRX is similar to 
other SDR software: it has the appropriate buttons 
for changing modulation, receiver frequency can 
be set by clicking on a signal shown on the 
waterfall display. An additional feature is the 
availability of the whole history of the waterfall 
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display: one can go back in time with the help of 
the scrollbar on the right edge of the window. The 
filter bandwidth can be changed by dragging the 
ends of the yellow filter shape shown above the 
frequency scale (see Figure 3). Additionally, to 
achieve the same effect as turning the passband 
shift (PBS) or the beat frequency oscillator (BFO) 
knob on a real radio, the filter shape or the VFO 
tick should be dragged with the mouse, while 
holding the shift key down. 


Fig. 3. Changing the filter bandwidth 


V. PERFORMANCE NOTES 


One of the greatest challenges in today's SDR 
receivers is the processing of the high amount of 
acquired data in real time. Even RTL-SDR is 
capable of bringing 2.4 Msps of 8-bit I/Q data into 
the computer, which means 4.8 megabytes of raw 
data to process every second. It is not a problem if 
you want to downconvert and demodulate a signal 
for a single user, but otherwise the CPU time 
required to process a block of data gets multiplied 
by the number of users. If too many clients are 
connected to an OpenWebRX server, and the CPU 
cannot handle the processing tasks for all of them, 
they will get lagging audio. Therefore it is 
important to optimize the settings to find the 
compromise between the high receiver bandwidth 
and the high number of users. There are several 
settings you can tune in config _webrx.py: 


* samp_rate: The sampling rate directly 
affects the CPU usage per client. The lower 
it is, the more clients can be served 
simultaneously. For rtl-sdr, some valid 
values are 250000, 1024000, 2048000, 
2400000. 


° fft_size: The waterfall display is calculated 
only once for all clients, but decreasing its 
resolution can still improve performance 
(and results in lower network usage as 
well). 


* max_clients: It is important to set this 
value to the safe maximum that will not 
result in lags. 


You can stress-test OpenWebRX by opening 
your URL in a lot of tabs simultaneously, 
preferably on another computer. Note that doing 
this requires sufficient CPU performance at the 
client as well. On the server, you can check CPU 
usage with the top command. 


You do not necessarily need a desktop PC to act 
as a server: you can also use one of the popular 
single-board computers (SBC) based on ARM 
processors. These cheap, small boards have low 
power consumption. It was reported by several 
users that the Raspberry Pi 2 is capable of running 
OpenWebRX, while the original, single-core 
Raspberry Pi is not sufficient. My tests on the 
Odroid-C1 board showed that it can serve at least 
10 clients when the sampling rate is 240 ksps, so it 
would be all right for sound-card based SDRs as 
well. The audio started to lag when the number of 
clients exceeded 15. 


On the other hand, running OpenWebRX on a 
quad-core Intel 17 CPU can serve 10 clients 
without problem at the RTL-SDR maximum 
sampling rate, 2.4 Msps, which is equivalent to 
processing 48 megabytes of data every second. 
This is not a bad result, regarding that we are 
talking about a general purpose processor. The 
CPU-critical process is the digital downconversion 
(DDC), which involves frequency translation and 
downsampling. Other DSP operations (like the 
actual demodulation and the AGC) work on a 
relatively low sample rate signal, so they do not 
take much CPU time. 


VI. SYSTEM OVERVIEW 


In the following part, the components of 
OpenWebRX are explained. The two main parts 
are the server application and the front-end 


running on the client computer (shown on Figure 
4). 


The server has been implemented in python, a 
very flexible scripting language, which has 
definitely helped to cut down the time required for 
development. Along with running the web service, 
the server spawns several processes which 
communicate via OS pipes and TCP sockets with 
each other and the server core. 


openwebrx.py 


 csdr processes» 
for client #1 
| csde processes” 


for client #2 


Client #2 
web browser 


Client #1 
web browser 


| openwebrx.js | 


Fig. 4. A more detailed block diagram of the 
System 


One of these processes is the well-known rtl_sdr 
command-line tool, which acquires the samples 
from the RTL-SDR device. In fact, it can be 
substituted with any other command that can emit 
1/Q samples to the standard output, so adding 
support for other SDR hardware should be easy, 
one just needs to change the command specified in 
config _webrx.py. 


The component used for distributing I/Q data 
between processes is rtl_mus.py, which stands for 
RTL Multi-User Server. I released this previously 
as a separate open-source tool. It acts as a TCP 
server to stream raw I/Q data to multiple clients. 
(The version packaged with OpenWebRX has the 
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raw I/Q data port restricted to local connections 
only, for use by other server components.) 


Every time a new client opens the webpage of 
the receiver, the browser initiates a WebSocket 
connection, which can be used for efficient two- 
way communication between the web server and 
the client (unlike traditional HTTP requests). 


On the server side my own WebSocket 
implementation is used, which resides in rxws.py. 
When the WebSocket connection is established, 
the server spawns a set of new csdr processes as a 
signal processing chain, which takes its input from 
rtl_mus.py, and outputs the demodulated audio. 
The audio is then sent through the WebSocket by 
the server core, along with the spectrum data for 
the waterfall diagram. The spectrum data is 
emitted by the spectrum thread, which is common 
for all clients and thus has only one instance. 


The front-end application running in_ the 
browser has been implemented in HTML5 and 
JavaScript: openwebrx.js manages the UI and the 
WebSocket, draws the waterfall diagram, and 
outputs the audio to the sound card using the Web 
Audio API. But before the audio can be output, 
some additional signal processing steps should be 
taken at the client side, which are performed by 
Sdrjs. 


vu. LIBCSDR 


The DSP functions behind OpenWebRX have 
been implemented as a standalone library called 
libcsdr. There are already existing software 
packages for this: GNU Radio is the most notable, 
which is used by many SDR software for Linux, 
e.g. gqrx, ShinySDR. One of the reasons why I 
chose to implement my own lightweight solution 
is that compiling the latest version of GNU Radio 
from source takes a lot of time, and it is sometimes 
difficult to do. Jibcsdr contains only the required 
functions for AM/FM/SSB/CW demodulation, and 
should compile in a couple of seconds, even on 
SBCs. 


I optimized the code for the auto-vectorization 
feature of the GNU C Compiler, so some DSP 
functions can make use of the SIMD instructions 
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in the CPU, although much more speedup could be 
achieved by hand written assembly code. 


VII. CSDR, A COMMAND-LINE TOOL FOR ANALOG 
DEMODULATION 


Another feature of the DSP library is the csdr 
command-line tool, which can be used to build 
simple signal processing flow graphs with one-line 
Linux commands. This is the wrapper around 
libcsdr that OpenWebRX uses. 


With csdr, prototyping a headless ham receiver on 
an ARM-based SBC might be quite 
straightforward. | Example commands for 
demodulating NFM/AM/SSB can be found on the 
csdr GitHub page [3]. For the sake of simplicity I 
rather present a one-liner for demodulating a 
WFM broadcast at 100.2 MHz: 


rtl_sdr -s 240000 -f 100200000 -g 20 - | \ 
csdr convert_u8 f | \ 

csdr fmdemod_quadri_cf | \ 

csdr fractional_decimator_ff 5 | \ 

csdr deemphasis wfm_ff 48000 50e-6 | \ 
csdr convert_f_i16 | \ 

mplayer -cache 1024 -quiet -rawaudio \ 
samplesize=2:channels=1: rate=48000 \ 
-demuxer rawaudio - 

In this example, to demonstrate the headless 
functionality, the raw I/Q data is taken from the 
output of the rt/_sdr tool, and at the end the 
demodulated audio is fed into mplayer, to play it 
on the sound card without the need of 
OpenWebRX. 


We perform the following processing steps in 
separate processes: 


¢ rtl_sdr -s 240000 -f 100200000 -g 20 - 


RTL-SDR outputs I/Q samples with a 
sampling rate of 240 ksps. 


¢ csdr convert_u8_f 


First we convert the §8-bit unsigned 
samples to floating point. 


¢ csdr fmdemod_quadri_cf 


We run a_ quadricorrelator FM 
demodulator, which turns our complex 
input signal into a real output signal. 


¢ csdr fractional_decimator_ ff 5 


We decimate the signal by a factor of 5, 
while also running a filter on it to suppress 
the possibly overlapping high frequency 
components. We get a 48000 sps signal at 
the output, which matches the sampling 
rate of our sound card. 


¢ csdr deemphasis wfm_ff 48000 50e-6 


We apply a de-emphasis filter with a time 
constant of 50 us. 


* csdr convert_f_i16 


We convert the floating point real samples 
to 16-bit signed integers to match the 
format required by the sound card. 


* mplayer -cache 1024 -quiet -rawaudio (...) 


We output the samples to the sound card. 


As the DSP functional blocks run in separate 
processes, the flow graph can take advantage of 
multiple CPU cores, if available. Scheduling is 
handled by the operating system. I was skeptic for 
the first time I have tried this, as I know the 
importance of scheduling in a dataflow system. 
While experimenting with OpenWebRX and csdr 
together, it turned out that this solution does quite 
good job even if about 50 processes are started 
when multiple users are present. In addition to 
multi-core processing, this implementation makes 
the flow graphs of OpenWebRX easily modifiable, 
as they are defined as a few lines in 
plugins/csdr/plugin.py, and also keeps Jlibcsdr 
code simple. 


IX. EXPERIMENTS WITH CLIENT-SIDE DSP 


The first release of OpenWebRX server 
required about 2 Mbit/s uplink network bandwidth 
per client, because I sent the 16-bit 44100 Hz raw 
sample stream through the WebSocket. In order to 
make OpenWebRX suitable for hams who want to 
share their receiver from their home Internet 
connection with a low upload speed, I added two 
processing steps before sending the data over the 
network connection: 


¢ I decreased the sampling rate to 11025 
Hz, which is still enough for NFM and 
SSB transmissions. 


* I applied IMA ADPCM compression to 
the audio. 


As a result, the required uplink bandwidth now is 
about 200 kbit/s with the default settings, of which 
about 70 kbit/s is the audio, and 130 kbit/s is the 
spectrum data. 


In order to restore the original signal at the 
client side, I had to implement the reverse 
operations in JavaScript. 


JavaScript has developed much in the last few 
years. It was traditionally an interpreted language, 
which resulted in with very poor execution speed, 
but with the introduction of JIT compilers, namely 
TraceMonkey in Mozilla Firefox and the V8 
Engine in Google Chrome, JavaScript is now 
feasible to build complex applications on. 


Some of the new, and still not widely known 
achievements on the scene of JavaScript are the 
Emscripten compiler and asm.js. The Mozilla 
Foundation has designed asm.js to be a subset of 
JavaScript that JIT compilers can easily optimize 
for, so performance is typically 50-67% compared 
to the speed of the native version of the same code 
[4]. Emscripten is an LLVM-based, source-to- 
source compiler to translate C/C++ applications 
into the asm.js subset of JavaScript. For example, 
companies use it to port games to the web, by 
compiling the original C++ code of the game (that 
was linked against OpenGL) into JavaScript code 
that uses WebGL, so the game can be played 
directly in the browser. 


Instead of porting some algorithms from 
libcsdr from C to JavaScript manually, I decided to 
compile the entire /ibcsdr package to JavaScript 
with Emscripten. The resulting JavaScript library 
has been called sdrjs, and contains all the 
functions that /ibcsdr has. However, there are 
some drawbacks. First, a lot of additional wrapper 
code had to be written to actually use the compiled 
functions. At this point only functions that are 
essential to OpenWebRX (like the IMA ADPCM 
codec and the resampler) have wrappers yet. 
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It is important to note that here I do only some 
post-processing on a signal with relatively low 
sample rate (<S50 ksps), so the 50% performance 
difference between JavaScript and the native code 
is not a problem. However, if someone would want 
to write a standalone SDR application running in 
the browser, the speed of the DDC operation and 
the FFT calculation would be limited compared to 
a native implementation, and also SDR hardware 
access is complicated from the browser (although 
Google's Radio Receiver application for Google 
Chrome, which has entirely been implemented in 
JavaScript, works in a similar way). 


Back to the compression, it is also worth to 
mention that the spectrum data is compressed, too. 
As it is a one-dimensional vector of dB values, it 
was not feasible to use an image compression 
algorithm like JPEG. I've had the idea to test 
whether ADPCM works on it, as the spectrum data 
is just like any other real-valued signal, and not 
that different from an array of audio samples. 
Surprisingly, I had good results, so I kept using it. 


X. REAL-WORLD USES OF OPENWEBRX 


OpenWebRX is currently used by only a few 
stations. 


Richard van der Riet, PA3GWH and Bart 
Weerstand, PA3HEA have been running their 
servers since February. Richard's server is 
monitoring the 30 meter band, while Bart's is 
currently working on 2 meters. 


With the help of Levente Dudas, HA7WEN I 
had the chance to do some testing on one of the 
machines of HASMRC Radio Club in Budapest, 
with a receiver connected to a Yagi antenna array 
automatically pointed to the JAS-2 amateur 
satellite during its pass. 


Antal Vincze, HG4FC was the first to test the 
OpenWebRX server in production environment at 
HASKAW club station in Nadap, Hungary. 


John Seamons, ZL/KF6VO_ has _ adapted 
OpenWebRX for use with his direct sampling HF 
receiver. 
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Alex Trushkin, 4Z5LV has made a version of 
OpenWebRX that is compatible with AFEDRI 
SDR. 


A few days before submitting the paper I have 
got the news that the first OpenWebRX server on 
HAMNET has become available, by Hans Reiser, 
DL9IRDZ, and there is one more to be set up soon. 


XI. CONCLUSION AND FUTURE PLANS 


Today's technology allows us to implement 
complex applications like an SDR receiver as a 
web service. A multi-user SDR receiver requires 
much more CPU performance than a single-user 
application, still we can find a compromise to let 
the application run on single board ARM 
computers. 


As young people of today have born into a 
world with computers and mobile phones, I hope 
that web receivers will make some of them 
interested in the great hobby of amateur radio. 


If you are further interested in the OpenWebRX 
project, you can find more information at the 
following website: 


http://openwebrx.org/ 


On this page, my Bachelor's thesis that I have 
written on this topic is also available for 
download. It contains more details about the 
implementation of both the web service and the 
signal processing. I hope it will help those who 
want to write the code for their own ham radio 
SDR receiver. 


The development has not stopped after 
submitting my thesis. The website for listing the 
receivers is expected to be ready soon. Users have 
requested many improvements, for example a 
squelch, and support for tablets, so there is a lot of 
things to do. The DDC could be much more 
optimized in order to be able to serve more clients 
from the same host, and using GPU hardware 
acceleration is also under consideration. 
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Modulation - Demodulation Software Radio 


Y ahoo user group: https://groups.yahoo.com/neo/groups/mdsradio/info 
MDSR website: http://users.skynet.be/myspace/mdsr 


Build your own IF SDR 
Introduction of MDSR V3.0 


Alex Schwarz, VE7DX W; alexschwarz@ telus.net 
Guy Roels, ON6MU; guy.on6mu@ skynet.be 


Accomplishments since the last publication 


Base Station setup 


The M DSR test station currently in use is a 
modified FT-950 from Y aesu. The transceiver is 
connected to aHy-Gain 18HTjr vertical antenna 
on top of a 3-storey building. Ground is 
connected to an iron riser pipe. The station is 
located on a foothill 10 miles north of V ancouver. 
Power output is 20W for digital modes and 100W 
for voice. 


The computer running the M DSR software is an 
i5 processor running at 3.4GHz with 8GB of 
RAM. The installed operating system is either 
64bit Win 8.1 or Ubuntu 14. The sound card 
installed is an ASUS X onar Essence true 24bit 
Performance. The on-board sound device isa 
Realtek High Definition on-board audio device. 


Mobile setup 


The mobile setup is a modified |C- 
7000. The antenna is a telescoping 
HF antenna from Hy-Gain (M F]- 
1979) with homebrew loading coils 
for 40 and 80m (left); used for 
stationary operations. A 4-band 
antenna (CR-8900 - 10m, 6m, 2m, 
70cm) is used while driving (right). 
The home made antenna rack fits 
multiple vehicles and can be 
transferred from one vehicle to the 
other in minutes. The rack includes grounding rods that can be connected on each 
end for better performance in stationary operation. 
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Mobile setup of MDSR in a Honda Element 


The!C-7000 radio is mounted in the lockable glove 
compartment which Is closed while the car is parked or the 
radio is not in use (computer and BiLIF are packed away 
ina box). 


The silver box on the dash contains the BiILIF unit and the 
X onar U7 USB soundcard, made by ASUS. 


The computer running the M DSR software is an ASUS 
Transformer T 100 book running Win 8.1 32bit. It also runs 
the digital communication programs for ] T-65 and WSPR 
which use the internal sound card. 


A USB hub connects all the devices together. The IF and 
the PTT connection come from the transceiver and plug 
into the BiLIF. 


Note: The 1C-7000 does not need a control head - all 
functions are performed by the M DSR software via CAT 
control. The |C-7000 control head is only used during 
mobile operations. 


Portable Setup 


The portable setup consists out of a modified FT-817, a silver box that contains the BiLIF and the USB 
sound device. The mic/headset plug connects to the web-book internal sound card for digital operation. 


The Portable MDSR system packed away in 2 travel cases for easy transportation 


On the left (smaller case) the antenna utility box contains all various antenna parts, such as loading 
coils, antenna extenders and the mounting bracket. The long rod across both cases is the M FJ -1979 
telescopic antenna which extends to 5m (15ft.). It does not fit into the cases and has to be carried 
Separately. 


In front of the small case is the Asus T-100 Transformer book, which runs the M DSR software. 
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The big case contains all the wire connectors, 
chargers, power adaptors, hub, spare batteries 
(8 x 2500mA/h NM H) and the antenna cable 
_ (hidden behind the lid cover) and the BiLIF- 
U7 sound device box (silver). The ASUS T- 
100 can be wrapped in towels and laid on to 
of the FT-817 for transportation. The standard 
NiCad battery pack in the FT-817 has been 
replaced with 8 2500mAh NiMH re- 
chargeables. The battery pack has been 
modified to allow charging of the batteries 
without removing them from the radio. 


The whole setup weighs less than 15Ib. One 
charge lasts for about 4h of operation (TX 
output reduced to 2.5W ).T he batteries can 
either be charged from the mains or with 12V 
from a cigarette lighter adaptor. 


Awards received and in progress 


e WAS50 in mixed bands for J T-65 mode 

e Worked all continents of the world in mixed bands for |] T-65 mode 

e 100 Grid Squares in mixed bands for J T-65 mode 

e Worked 53 states (confirmed 44 on e-qsl and 31 on QRZ.com) as of J une 2015 


Hardware 

The LIF 2014 kit was released. The schematics and the components are identical to the previous 

LIF 2012 kit that has worked so reliably. The only update was the footprint of L1 to make it easier to 
assemble the unit. 

A lot of Hams have already built and implemented the kit into their station setup; they use it every day 
for standard operations. 


Software 


The M DSR Team has released the M DSR V2.9 last fall. This release added notch filters and adaptive 
filters for SSB, CW and broadcast audio. The graphic user interface was also changed to allow for 
better navigation and to reduce the footprint on the screen. If the MDSR is used only for RX operation 
the window size can be reduced to only show the button and display for this task. 


The post-processing filter options 


Depending on the mode the M DSR is in, different filter options are displayed. This allows the 
optimization of each post-demodulation filter for better overall performance of the MDSR while 
receiving. In addition to a variable bandpass filter, one auto notch and one manual notch filter can be 
utilized to eliminate interfering signals. 


Note: AM mode does not have an auto notch filter. 
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Version 3.0 was launched in February 2015. It received a totally new DSP engine to upgrade to the 
Jsyn 100% J ava sound synthesizer. Now the M DSR core software can be adapted to all J ava capable 
computers such as Linux, Ubuntu and A pple. 


The M DSR V3.0 can be downloaded from our website and used for free for amateur radio purposes. 
For more info please visit our website or join the Y ahoo user group. 


New S- and Power Meter for the MDSR V3.0 


The updated RF meter features a dual color display for RX. It turns RF Meter 
blue while in TX mode. In receive the scale is in S units, and the 12345678 940440 
meter displays Pout [%] during transmit. 


2 50. 75 ~=«(100 


RX Power [5] TX rel, Power [%] 


The new “MDSR SA” Spectrum Analyzer Eater: sh SSh | anos UE 


Introduction 

Implementing the latest J syn DSP software in the M DSR V3 also gave us access to advanced signal 
processing devices such as FFT and IFFT conversion units. Our team started to develop a spectrum 
analyzer by using a spectral filter. This filter creates a 420 line audio spectrum (0 - 20 kHz) witha 
resolution of about 47Hz per line. After the first attempt to connect the SA to the IF of the LIF 
converter the result was encouraging, but the bandwidth response of the receiver's IF looked like a 
“hump”. This made the detection of signals very cumbersome and useless for level comparisons. 


The idea was born to compensate each spectral line individually so that the result was a flat spectrum. 
This is not practical, though, because it would take the user hours to adjust all 420 line levels 
individually. Sweeping the bandpass was another option, but this would require a RF sweep generator. 
M ost amateur radio operators do not have access to such an instrument. A nother option was to measure 
the receiver’s filter responses with RF noise, by tuning the radio to an unused section of the band and 
then taking a noise peak measurement for each frequency line. 


The noise that is received on the antenna port is constant over a wide part of the spectrum. Therefore 
all the level differences are caused by the filter pass of the input and IF filters. So what looks likea 
“hump” - when noise is received - is really a flat spectrum. Now the DSP could be programmed to 
measure the peak level of each spectral line, calculate its attenuation and store the result in a table. 
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To obtain a flat spectral readout now only requires a simple multiplication of the corresponding 
attenuation factor by the current spectral input level. The result is a displayed spectrum that is flat. In 
essence the effects of the receive filtering, which are important for the radio’s performance, have been 
mathematically removed. 


How do Spectral Filters work? 
Introduction 


Spectral filters are a very interesting way to manipulate and create signals. The standard oscilloscope 
only measures voltages as the sum of electron pressure in conducting materials over time. It does not 
provide a frequency-separated display that shows the dynamic behavior of all the different groups of 
electrons that make up the electric current. These groups of electrons can move back and forth at 
different speeds (frequencies). The more electrons move in one direction, the higher the amplitude. 
Frequencies or tones are in essence oscillating electrons. 


If tones are to be manipulated, it is much easier if the signal is separated by frequency (tones) than by 
time. Unfortunately it is much harder to display electrical behavior of a conductor in the frequency 
domain than in the time domain of an oscilloscope. This is also truein DSP (digital signal processing). 


What is FFT (Fast Fourier transform)? 

In DSP the frequency domain is so important that engineers developed special programs called FFTs 
that take streaming audio or video data and separate it into multi-channel data flows. FFTs can have 
1000 or more channels separated by frequency; these are termed bins. These individual data flows can 
now be observed by frequency and amplitude for a specific behavior. A host program can display the 
data as a spectrum on a screen or make decisions if certain signal patterns are present. The applications 
of this technology in the radio field alone are almost limitless. 


What is IFFT (Inverse Fast Fourier transform)? 

In DSP, IFFTs has an almost equally important role. IFFT and FFT are mostly used in pairs. Whereas 
FFT separates the input signal into different frequency channels the IFFT does exactly the opposite. It 
takes all the FFT bins - after they were processed - and combines them together into a time domain 
output that can drive a speaker after it has been turned back into an analog signal by aDAC (Digital to 
Analog Converter). 


Applications 

Removing unwanted frequency bands 

Shifting frequencies or bands of frequencies up and down 
Removing unwanted carriers or static crackle 

M odulation and demodulation (digital or analog) 

Adding control tones 

Creating noise 
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Spectral Filter example with FFT / IFFT pair of 420 channels (BINs) 
AnAM Signal is fed to the ADC and changed into a stream of numbers relating to amplitude. 


-10 
U[V] 


Oscillograph of an AM signal 


The now digitized signal is put through a DSP process called FFT 
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Spectral representation of a FFT 
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The FFT filters frequencies and stores the signal stream in BINs (table representation) 


135 


Signal manipulation based on frequency (removing Bin 210 - 212) 


U [Vv] 


Spectral representation of a FFT 
(removing carrier) 
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Performing an IFFT (Inverse Fast Fourier Transform) and sending the data stream to a DAC will 
recreate the analog signal without the carrier. 


U [VJ 
Oscillograph of an DSB signal 
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Disadvantage of FFT filters 

¢ All the data manipulation is processor intensive and delays are an issue. The program needs to 
reduce the amount of DSP data to the bare minimum before executing DSP functions. The 
software instructions need to be as basic as possible. A void coding that requires access to 
higher functions or peripherals such as keyboard, mouse or displays. 

¢ TheDSP processes can create huge amount of data. A 24-bit DSP chip with an FFT having 
1000 channels and a sample rate of 192kHz creates 4.608M B of data every second! 

¢ A fast computer is required to get the speed performance needed. Good coding can assist in 
reducing processor requirements. 

¢ Signals can sound tinny and robotic due to the FFT- IFFT process. A good understanding of 
how to configure the DSP properly is a must. 


¢ Thehigh price of components and the availability of high resolution digital converters are 
limiting factors. 
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MDSR SA 


Introduction 


The new spectrum analyzer is written 100% in J ava - including the DSP - and enhances the MDSR software on 
a Linux platform. Since itis written in J ava it also will work with the existing 
MDSR installation in Windows. 


One of the issues with viewing an IF spectrum from an analog transceiver via a sound card interface is the 
inconsistency of the IF amplitude and the narrow bandwidth. This makes the spectrum look like a hump with no 
signals on either side. To overcome this we have developed anew feature called SAC (spectral amplitude 
correction) which measures the attenuation of the IF and applies a correction value that greatly flattens the 
spectrum. 


This document will also explain how to install and run the software in the above mentioned operating systems. A 
detailed manual is also provided. 


This is a working document which will grow in size as we explore the possibilities of this new software. If you 
would like to join us and work on the continuing project, please register at the 


MDSR Yahoo user group here: 
https ://groups.yahoo.com/neo/groups/mdsradio/info 


Information on how to connect a receiver or transmitter to the soundcard can also be found at our 
website hosted by Guy Roels (ON6MU): 
http://users.skynet.be/myspace/mdsr 


Acknowledgement: 
Special thanks go to Phil Burk for providing the J syn FFT sound interface free of charge for this project. 


Installing on Windows with MDSR already installed. 


Download the “Spectrum Analyzer. jar” from the Yahoo use group. Look in the file section in the “New SA for 
MDSR’" folder. Copy the file into “MDSR” directory. Create a desktop shortcut. The program is started by double 
clicking the file or shortcut. 


Note: If the spectrum analyzer is used without the MDSR, additional library files are required. 
Create a “lib” folder inside the folder holding the “Spectrum Analyzer. jar”. This “lib” folder and its contents can 
also be downloaded from the group. 


Installing on Ubuntu (Linux), Apple Computer 


Download the “Spectrum Analyzer. jar” from the Yahoo user group. Look in the file section in the “New SA for 
MDSR’"” folder. Copy the file into MDSR directory. Create a desktop shortcut. The program is started by double 
clicking the file or shortcut. 


* Make the file executable by going into properties - permissions and checking the “Allow executing file 
as program” 


Note: If the spectrum analyzer is used without the MDSR, additional library files are required. 


Create a “lib” folder inside the folder holding the “Spectrum Analyzer. jar”. This “lib” folder can also be 
downloaded from the group. It contains three files that are required to make the program work. 


Press the “Start” button to turn the spectrum analyzer on 
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Setting up the Soundcard or Device 

The sound setup of the “New MDSR Spectrum Analyzer” is identical to the setup of the MDSR software. It 
always uses the default audio device, and can share it with other software at the same time. For more 
information on how to install and configure the LIF converter, go to the MDSR website or user group. If you have 
already set up the MDSR software, all the audio settings are identical. Both programs can work simultaneously 
without mutual interference. 


Functionality of the Spectrum Analyzer 


Introduction 
This spectrum analyzer provides a span of spectrum for the audio spectrum of a sound card. It is designed to 
work with the MDSR software, but can also be useful for analyzing audio spectrum. It has a peak hold feature 


and a slow decay indicator. 
The new SAC (spectral amplitude correction) feature and how to use it will also be covered in this manual. 


Updated in the new version V1.1 


* New line decay mode: double spectral lines in “decay-line mode”. 

*Input Audio selector: allows the user to select the left, right or both input audio channel 
* Storable correction curve files: correction curves can be stored according to band 

* Spectrum analyzer stores previous settings: for easy startup without calibration 

¢ Updated graphic user interface 


The new MDSR Spectrum Analyzer V1.1 


Below is the graphic user interface for the new MDSR Spectrum analyzer with the corrected display. The DSP 
removes the filter skirts which cause the spectrum to appear bent downwards at the edge of the filter passband. 
A flat spectral trace - like the one on a high-end lab spectrum analyzer - is displayed. 
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Correcting the filter skirts to obtain a flat spectral response 


Correction Procedure 


The correction procedure is a two step process where the filter noise response is captured and stored in the 
computer. Once the curve had been captured, itis applied to the spectrum and a normalized spectral display 
results. The filter noise response depends on the noise loading and the band the transceiver is on. The noise 
response can be saved and recalled for each band separately. 


How to calibrate and correct the filter response in the MDSR SA 
Depending on the speed of the computer used, this calibration will take about 10s or longer. 


1. Tune the receiver on the specific band in use to an area that has no signals. Set the attenuators to 0dB 
and the preamps to OFF. 


2. Under the “Corrected Spectrum” heading set the selector box to “normal”. The spectrum changes back 
to the real display with the filter skirts (Fig. a). 


3. Press the “Equalize” button and a display similar as seen below appears (Fig. b). The white dots 
indicate the flat response of the corrected spectrum. The green line represents the correction values. If 
the green line is not visible, move the “y-Gain’ and/or the 


“Ref.Level” controls until it becomes visible. If there are signals present, they will be seen as large 
spikes on the filter curve. Tune to another spot without signals and repeat the measurement starting at 
1. Small spikes, like the ones below, will be filtered out and a flat spectrum is displayed. 


4. Press the “Correct” button to verify the correction line and to display the corrected flat display. Use the 
“y-Gain” and/or the “Ref.Level” control to adjust for best visibility. 


5. Ifthe spectral line is not flat, repeat the process. 


Note: The measurement must be done with the antenna connected, so as to obtain band noise to measure the 
filter response. 


Calibrate and correct the filter response in the MDSR SA using a white noise generator 

The spectrum display correction curves can also be generated with the use of a wide band white noise 
generator, such as the MF] -5014. To get the best results, the antenna noise level and the generated noise level 
have to be identical. 


The output of the generator is connected to a step attenuator such as the MF] -762 and then to the antenna 
input of the receiver. If the receiver has dual Antenna inputs, the RF noise can be connected to Ant 2, while the 
regular antenna is connected to Ant 1. 


Connect the Antenna to the receiver and set the attenuators to 0dB and the preamp to OFF (Ant 1). 
At the receiver, select the band to be measured. 

In the “Level [dB]” box (bottom left) note the displayed level in the “noise” field. 

Connect the receiver to the noise source (Ant 2). 

Adjust the attenuator so that the displayed noise level is the same as that from the antenna. 
Continue the above procedure at #2. 


OY ee ee 


How to store the filter response in the MDSR SA for later recall 

Once a flat filter response correction curve has been calculated and the corrected spectrum is flat, itcan be 
stored on the computer's hard drive. Since the flatness of the display is dependent on the band and the noise 
loading, the MDSR SA has the capability to save one correction curve per band. Currently the MDSR SA stores 
curves for 160, 80, 60, 40, 20, 17, 15, 12 and 10 meters. After a flat spectrum has been calculated, it can be 
archived by following the above procedure for a specific band: 


1. Under the “Correction Curve” heading, select the band that is currently in use. 
2. Press the “Save” button. This will store a file containing the correction values. 
3. Repeat the above procedure until all bands have a correction curve file. 


139 


How to recall the filter response in the MDSR SA 


1. Under the “Correction Curve” heading select the band thatis currently in use. 
2. Press the “Load” button. This will recall a file containing the correction values. 
3. The displayed spectrum is now corrected and should be flat. 


Note: If the selected band does not have a correction curve, a warning message will appear. 
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Fig. c.) Spectral Display after correction (bar graph — decay option 
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Description of the user functions. 


Introduction 

This section describes the all the individual user controls and how they affect the displays and functionality of 
the MDSR SA software. Familiarization with their use and effects will allow you to adjust the display properly 
and to get the most out of this program. 


Start Button 
The “Start” button initializes the DSP and turns the spectrum analyzer on. 


RST button 

During operation, some sound devices build up a delay over time. This occurs, because the clocks of the FIFO 
data exchange buffers are not synchronized (a hardware issue). If there is noticeable delay, the “RST” button 
can be pressed to reset and clear audio buffers for lowest lag time. 


Exit Button 
The “Exit” button stops and removes the DSP engine from the computer and closes the program. 


Dominant 
The “Dominant” field displays the frequency value of the spectral line with the highest value. 


When the spectrum is corrected, the highest amplitude may not be the dominant frequency. 


Option (selector box) 
The “Option” selection box has three options. 
e Normal: (default) displays the spectrum as a single graph. 


e Peak hold: displays the graph including its highest value. The highest value is held on the 
display indicating its frequency position. 

e Decay: displays the normal graph including a time-lagged, delayed decay graph. This makes it 
easier to spot intermittent carriers. 


Graph (selector box) 
The “Graph” selection box allows choosing the line display or the bar graph display. The “line” setting is the 
default start up parameter. 


Y-Gain 
The ‘Y-Gain” slider changes the amplification of the displayed spectrum. It acts like a volume control and makes 
the spectral peaks longer or shorter depending on the setting. 


Ref. Level 

The “Ref. Level” control shifts the displayed spectrum up and down so that it can be placed properly in the grid 
display for easy readability. The control acts similarly to a fader on a stereo system. “Ref. Level” does not 
change the amplification of the display, but only its position. 


BW (selector box) 


The “BW” selection box provides three settings 

e 20 kHz (default) provides a spectral display with 420 points at a resolution of 47 Hz. For the MDSR or IF 
display the 20 kHz selection has to be used to allow for proper placement of the red BFO line. The 
displayed spectrum is 0 - 20 kHz. 

e The 10 kHz option can be used for audio processing and analysis. The spectrum displayed is 0 - 10 
kHz. It will not center on the BFO line on the IF signal. It also has 420 display points with a spectral 
resolution of about 23 Hz. 

e The 5 kHz option can be used for audio processing and analysis. The spectrum displayed is 0 - 5 kHz. 
It will not center on the BFO line on the IF signal. It also has 420 display points with a spectral resolution 
of about 12 Hz. 


141 


V-Filter (selector box) 

The ‘V-Filter” (video filter) processes the spectral data and acts like a low pass filter to make the displayed 
spectrum smoother. There are five levels of filter intensity; 1 is the weakest and 5 the strongest. In the lowest 
setting (1) all the individual spectral lines are displayed. In the strongest setting the display lines are combined 
making it easier to see the spectral intensity of a SSB or broadcast signal. Default setting is 3. 


X-Grid (spinner selector) 
The “X-Grid” selector allows calibrating the spectral display with an internal or external signal source. The 
spectral display and the grid do not automatically line up, so it needs to be calibrated manually. 


e Calibrating using the internal reference signal: 
Set BW to 20 kHz, and turn on the “Test Signal’ generator by setting the spinner control to 10. This puts 
out a white noise signal with sine wave peak at 10 kHz. Now, use using the “X-Grid” control, move the 
spectral peak behind the red center line. This will also calibrate the 5 kHz and the 10 kHz bandwidth 
selection. 


e Calibrating using an external reference signal 
The “X-Grid” control can also be used to be aligned with an external signal such as the carrier of an AM 
station, the radio’s calibration marker or a BFO. In this case the computer soundcard needs to be 
connected to a LIF converter and a receiver. 


Test Signal [kHz] 

The ‘Test Signal” selector allows adding an internal noise source and sine wave oscillator to the input of the 
spectrum analyzer. The test signal can be used to simulate the input for display or calibration purposes. Setting 
X-Grid (Spinner selector) to 0 will turn the test signal off. Now the DSP is set to accept input from the audio 
default device. 


Refresh Time 

The “Refresh Time” default setting is “O”. This setting is the fastest, and if a P4 or higher processor is used the 
spectrum refresh rate is high enough to provide a nice, dynamically flowing spectral display. The FFT process 
needs a lot of processor time, and it can easily consume 60% CPU resources or more. This may affect other 
applications, and therefore a refresh time throttle is needed. Set the refresh time lower if other applications start 
to hang or are otherwise affected during the operation of the spectrum analyzer program. The refresh time 
indicator displays the time in mS for each sweep. Newer processors can be as fastas 1 to 2 mS. 


Equalization (selector box) 
The “Equalization” selector has three options. 


e normal: the displayed spectrum is not corrected 
e corrected: the display is normalized using the loaded correction curve. 
e Calibrate: this is used only during the calibration procedure - do not select manually. 


Equalize button 
The “Equalize” button should only be pressed after the receiver has been tuned to a section of the band without 
signals. During this operation, the DSP measures the filter response curve which can be viewed on the display. 


Correct button 
The “Correct” button activates the currently active (loaded) correction curve and corrects the spectral display. 


Select Input 
The input selector chooses the input channel of the default sound card. Three options are available (both, left, 
right). 


Level [dB] 

Under the “Level” label there are two fields that display the average noise level and the peak level per scan in 
dB relative to 1Vpp. These two variables are used to determine the bin with the highest amplitude, so as to 
calculate the dominant frequency value. The noise level indicator is also used for correction curve 
measurements. 
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Bin Value Evaluator 
The “Bin Value Evaluator” consists of the bin value field and the bin number selector. The bin value field 
displays the correction value of the bin selected. This allows the user to view and edit stored correction values. 


Note: A red marker bar is displayed in bar graph mode indicating the position of the displayed correction value. 


Corr Button 
The “Corr” (correct) button calculates the current displayed bin correction value by taking the adjacent values 
and averaging its position. This can fix miscalculated values which can cause holes or peaks in the spectrum. 


Man Button 
The “Man” (manual) button updates the manual entered correction value for the displayed bin. 


Correction Curve 

In the correction curve box, the option box selects the band that either saves or loads the correction curve data 
into the DSP. The “Save” button save the currently active correction data. To recall correction data, the “Load” 
button is pressed. The display is updated immediately. 


Congratulations! 

Now the new Spectrum analyzer for the MDSR is working and calibrated. Please follow the instructions and tune 
the new MDSR SA for best performance. We hope that you will have a great experience with the new spectrum 
display. If you have any questions or recommendations regarding this software or would like to get involved, 
please join us at the Yahoo user group: 

http://groups.yahoo.com/group/mdsr/ 

Thank you for using the MDSR. Please tell your friends about this project. 

All the best, 


MDSR Team 


June 2015 
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Design of a Practical Handheld Software Radio: Part II 


Chris Testa, KD2BMH 
Los Angeles, CA 
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Abstract 


The design of a standalone battery powered Soft- 
ware Defined Radio (SDR) is presented. Three 
rounds of prototypes were designed, built, and 
tested over the last three years. The hardware ar- 
chitecture of the newest design is detailed, with 
the goal of getting the device into the field to 
build real RF links. The software stack, from 
the high-level websocket user interface down to 
the embedded Linux operating system are dis- 
cussed. Finally, the latest work on the Field Pro- 
grammable Gate Array (FPGA) modem are pre- 
sented, including optimization work that drasti- 
cally improves simulation performance. 


Keywords 
software radio, low-power, embedded systems, 


Linux, FPGA, DSP, quadrature transceivers, RF 
system analysis 
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1 Introduction 


In 2012 I reported my first success along the 
way of developing a new type of Software De- 
fined Radio[1]; one in which the whole SDR is 
contained in a single, portable unit. I was espe- 
cially inspired to do this for my love of backpack- 
ing, and I continually find myself in the position 
where I really want to have radio communica- 
tions available in places where today you can’t 
expect them. 

The dream, as Eric Blossom wrote in the ar- 
ticle Exploring GNU Radio[2], is to stretch the 
*smarts” of the Internet out from the cell towers 
to everyone’s smartphone. The belief which I still 
hold today, is that if we all carry around a base 
station, we will be well on our way to distributed 
and fault tolerant Internet access worldwide. I 
know that this is a lofty goal, but with the right 
tools we can begin to explore new frontiers in 
networking. 

My key goals for the project are to: 


e Design and build a standalone, software de- 
fined transceiver that works with commonly 
available Amateur radio modes. 


e Make it easy to use by providing connectiv- 
ity and extensibility layered on top of Open 
Source software. 


e Focus on small footprint and low power 
consumption to enable portable operation, 
much like with a cellular modem chipset. 


At the time I presented at the DCC 2012, I had 
never designed or laid out a radio circuit board 
before. I studied Computer Engineering at the 
University of Maryland, College Park, and I’ve 
loved ripping apart computers from a young age. 
Radio Frequency circuits are an entirely different 
beast, however. There’s a huge learning curve to 
building a SDR from scratch, and the remainder 
of this paper will detail the evolution of the de- 
sign, and the things which I learned along the 
way. 


2 Hardware 


2.1 Design Evolution 


The first pre-alpha design was completed thanks 
to the WIESEL laboratory at the University of 
Utah, and with the help of my good friend Aaron 
Schulman. Aaron at the time was finishing his 
PhD in Computer Science at University of Mary- 
land. I built the first transceiver by ordering de- 
velopment kits for all of the main integrated cir- 
cuits I wanted to use: a SoC FPGA!, a quadra- 
ture transceiver, a frequency agile VCO & PLL, 
and Analog to Digital / Digital to Analog con- 
verters. Plugging them all together, and getting 
access to a real RF lab, meant that I could build 
the proof-of-concept and make sure that the core 
idea was sound. 

Building a radio from discrete components 
turns out to be a difficult problem. The art 
of building a receiver is a complex and detailed 
one, full of tradeoffs between power, price, per- 
formance, size, and many other factors. Further- 
more, a core concern for me was that I needed 
to build a quality transmitter as well. This ulti- 
mately turned out to be the most difficult chal- 
lenge. 

The first custom board, Whitebox Alpha, was 
built at the University of Maryland, College 
Park, with the help of Aaron. The build oc- 
curred four months after the first time I presented 
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Figure 2: Whitebox Bravo 


the design at DCC 2012. I fabricated two 4- 
layer PCBs with Sunstone Circuits, and ordered 
parts from major distributors in the USA includ- 
ing Digi-Key and Mouser. I also ordered a sol- 
der paste stencil. Most of the components were 
on the top, so I solder-pasted the side and then 
carefully placed the components with tweezers. I 
used a hot plate to solder on the components. It 
worked quite well, except for the connector for 
the computer, which I had to have professionally 
put on to get a good connection. Ultimately, the 
computer worked on this design but the IF os- 
cillator was unable to lock reliably, due to me 
messing up the nets around the PLL Loop Filter 
and VCO’s tank circuit. 
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Figure 3: Whitebox Charlie 


Whitebox Bravo was built at a contract man- 
ufacturer (CM) in Carlsbad, CA, and I really 
enjoyed using the surface mount assembly line. 
This one came together around one year after 
the build of Whitebox Alpha. My goal here was 
to really focus on the core RF system and ver- 
ify that I could design a PCB that would radiate 
RF. The design had around 130 components on 
it, and I was able to get all of the PLLs to lock. 
I began to work on the full RF signal chain. A 
major problem that I had still at this point was 
that I had no RF test gear. In particular, if you 
plan to make a radio without a calibrated RF 
Signal Generator and RF Spectrum Analyzer, I 
wish you luck! Those tools are critical to under- 
stand the behavior of your creation. 


After a year of working on Whitebox Bravo, 
Bruce Perens K6BP started to acquire Boat An- 
chors and ship them my way to help me be able 
to understand the intricacies of the second pro- 
totype. The lessons were clear - the various sub- 
circuits need appropriate RF filtering to connect 
them together, and the transmitter needed addi- 
tional circuitry to calibrate it for spurious emis- 
sions requirements. Given that I could solve both 
of those problems, the device would be ready for 
serious amplification and to be used by others. 


Whitebox Charlie, was designed over a 7 
month time span starting directly after the DCC 
2014 Sunday Seminar that I did on FPGA 
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SoCs|5]. This board is a full five times more com- 
plicated than the previous design. The goal this 
time was to get the board off of my bench and 
into the field. It sits inside of a 160mm x 75mm 
extruded aluminum case from Hammond Mfg. I 
use U.FL connectors on every important RF net. 
I can always not stuff them after I’ve figured out 
the design issues. The fabricated PCB is 6 lay- 
ers and the additional two microstrip layers allow 
for a much more dense route while maintaining 
signal integrity for the critical RF traces. 


2.2 Baseband Subsystem 


The entire design received an overhaul based on 
the lessons learned from the previous prototypes. 

For power input, there is transient voltage sup- 
pression, reverse polarity protection, and high 
voltage filtering to condition the noisy signal 
coming from a car battery as it is charged via 
its alternator. Two on-board switching regula- 
tors provide efficient digital power at 3.3 and 
5 Volts for the embedded computer and its pe- 
ripherals. A wide input-voltage tolerant 5 Volt 
Low-Dropout Regulator (LDO) provides analog 
power, and a 3.3V regulator stems off of this 
for the analog circuits on the baseband. The 
analog portion of the board can be turned off 
from the microcontroller by setting a global En- 
able flag low. Wakeup times from this state 
should be on the order of 100ms. There are other 
standby modes available that trade wakeup times 
for static power dissipation. 

The System on Module contains the baseband 
embedded ARM Cortex-M3 and FPGA [3]. It 
is in a separate daughter card which plugs into 
the main board. The main reason to not place 
this component myself is to not have to deal 
with the 484 pin BGA package, in addition to 
the BGA packages for the on-board LPDDR 
RAM (64MBytes) and Flash (16MBytes). Rasp- 
berry Pi B+ 40-pin and 8-pin (mostly) compat- 
ible headers are available for custom expansion. 
You'll have to try individual boards to see if they 
fit, and to see if you can get the driver ported. 
I expect most WiFi, Bluetooth, GPS, and Au- 
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Figure 4: Baseband Subsystem Schematic 
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dio CODEC devices to work out of the box, but 
your mileage may vary. I maintain a official list 
of working devices in the codebase. 

The system module supports standard com- 
puter peripherals including USB On The Go 
(OTG) and 10/100 Ethernet. There are 6 LEDs 
on board covering RESET, Power, PTT, and 
three for user control. The RESET and PTT sig- 
nals also expose Open-Drain outputs so that way 
you can control much higher voltage equipment, 
like a 100W power amplifier and a T/R switch. 
The only externally exposed button is a RESET 
button, but there is a 100-mil header ready for 
you to tap in for Reset, PTT and dit-dah paddle 
inputs. All inputs are double-layer Electrostatic 
Discharge (ESD) protected for ruggedness. 


The clocking subsystem uses a_ high- 
performance, low phase noise 10MHz Tem- 
perature Compensated Crystal Oscillator 


(TCXO) to provide the main sampling clock 
for both the analog and digital sections of the 
mixed signal system. A clock buffer distributes 
the signal to the PLL reference inputs, as well 
as to the ADC and DAC. A transformer coupled 
external 1OMHz reference can be applied as well, 
and switched in by changing a jumper. 

The CODEC is the most important set of com- 
ponents for transceiver performance on the base- 
band side of the design. For this project I am 
building a quadrature sampling transceiver, so 
the ADC and DAC must be of the dual, simul- 
taneous sampling variety. This design features 
operational amplifiers at the inputs and outputs 
of the ADC & DAC respectively. The reason 
for this, which I did not understand for earlier 
designs, will be explained later in the section 
on overall system performance. A tradeoff must 
be made between sampling speed, sample reso- 
lution in bits, and power consumption. In this 
case, I chose a 10-bit ADC and am operating it 
at 1OMSPS. The DAC is also 10-bit, LOMSPS. 
We would ideally move to 12-bit models, but the 
oversampling does help somewhat for maintain- 
ing overall system dynamic range. 

An additional 8-channel auxiliary ADC is used 
to observe the following signals: transceiver tem- 
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perature, input power voltage, received signal 
strength, transmitter calibration signals, and 
PLL test points. An additional 4-channel aux- 
iliary DAC is used to calibrate the baseband 
transmit signal coming out of the communication 
DAC. The objective of this circuit is to minimize 
local oscillator feedthrough. The transmitter cal- 
ibration routine will be described in more detail 
in the next section. 


2.3. RF Subsystem 


The RF portion has its own power tree to iso- 
late the subsystems as much as possible. Numer- 
ous rails are required, and LDO’s were chosen for 
low noise and high Power Supply Rejection Ra- 
tio (PSRR). There’s a 3V rail for the Low Noise 
Amplifier, a 3.3V Rail for the VCO’s, and a sep- 
arate 3.3V regulator for the rest of the analog 
subsystems. A 1.8V LDO supplies current to the 
RF Gateway. 

The RF Gateway is a simple SPI slave designed 
in acheap CPLD from Xilinx. The gateway talks 
to the main computer via SPI, and then con- 
trols the various RF and amplifier switches. This 
turned out to be cheaper than using discrete logic 
gates, and is safer than using just GPIOs. For 
example, it’s not possible to turn on the Power 
Amplifier when receiving, thus reducing the like- 
lihood of blowing the amplifiers. 

Due to the superheterodyne architecture of 
the quadrature transceiver, two local oscillators 
are needed. The first oscillator works with the 
quadrature modulator & demodulator to go from 
the fixed Intermediate Frequency of 9OMHz down 
to baseband. Since this oscillator’s frequency 
never changes, it’s Loop Filter is optimized to 
trade lock times for reduced phase noise. 

The second oscillator works with both the re- 
ceiver’s mixer, as well as the transmitter’s im- 
age reject up converter. This oscillator has 
very demanding requirements. It needs fine fre- 
quency resolution, fast lock times, and low phase 
noise. These conflicting requirements means that 
a tradeoff has to be made. Both oscillators have 
available U.FL connectors so a new oscillator can 


>» 


HINSTON BOL SHY Aq uae SOT 
07500 11224 ya. 

OW MEY XOgoRTAN : 
YOISTADY. 2z1$ 

pod Aa 


DLL 


SOS ae TE 


DOCHDS Aeaares 


ped Ta 
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be plugged in depending on the application. 

The core transceiver chip comes from CML 
Microsystems|4]. This transceiver has a very de- 
tailed manual and I’ve read it more times than I 
care to admit. There are many features of this 
chip and I will explore some of them later when 
we get to talking about the integrated design. 

Between the core transceiver and the antenna 
jack, there sits a lot of additional RF circuitry 
that was not in the Bravo design. On the trans- 
mit side, after the signal leaves the transceiver 
chip, it flows into one of four bandpass filters in a 
selectable filter bank. The goal is to cut out spu- 
rious emissions that leak in from the harmonics 
of both oscillators. 

After filtering, the to be transmitted signal can 
be sent down two paths: the first is to the power 
amplifier (20dBm maximum output) on the way 
to the antenna, while the second path goes to 
a RF log detector. The Log Detector is used to 
measure the signal strength of spurious emissions 
and is used to calibrate the transmitter’s oscilla- 
tor leakage and undesired-sideband suppression. 

For the receiver, a switch lets you choose be- 
tween two different signal sources. One comes 
from the transmit-receive switch, while the other 
comes from a built-in RF noise source. The noise 
source is built using an avalanche diode that is re- 
verse biased very close to its breakdown voltage. 
The output of this signal is amplified and pre- 
sented to the receiver chain as a self-test feature. 
Whichever receive signal is chosen, it then flows 
through the onboard bandpass filter bank and 
into an LNA. The LNA provides 14dB - 20dB of 
gain depending on the frequency. The final step 
as an RF signal is through a matching network 
on the way into the transceiver chip’s mixer. 


2.4 System Performance 


A very important step, which was accomplished 
early in the Carlie design phase, was to do a full 
RF System analysis. The goal here is to start to 
look at how the transceiver would operate in a 
real RF link. An important thing to remember 
while reading this section is that when we talk 
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about RF signals, we really want to talk about 
power, and not in terms of voltage, current and 
resistance. So put aside Ohm’s Law for the mo- 
ment (though don’t forget it!) and remember the 
power laws P= IV = V?2/R=TI°R. Also, we'll 
be using decibels everywhere, so we can just add 
the power terms together to get overall system 
power. 

For the receiver, a signal is present at the an- 
tenna of lets say -110dBm at 50 Ohms. First, the 
signal flows through the T/R switch, the receiver 
signal switch, and the bandpass filter, which at- 
tenuates the signal by 6.2 dB, bringing it down 
to -116.2dBm. Next, the LNA is applied. The 
LNA provides 15 dB of gain, bringing the signal 
back up to -101.2dBm, while only increasing the 
noise by 0.6 dB. 

The next sections of the receiver chain are fo- 
cused around the transceiver chip. A 1:1 trans- 
former balun and matching network brings the 
impedance up to 300 Ohms to be matched to the 
mixer. Its after this mixer stage that one of three 
possible bandpass filters can be selected: 1MHz, 
100kHz, or 30kHz. The selected filter bandwidth 
plays an important role on the final Signal to 
Noise ratio as seen after the quadrature demod- 
ulator. This is because the narrower the IF filter, 
the less noise power that makes it through to the 
ADC. 

Now comes an important step which I did not 
include in the Bravo design - there is an opera- 
tional amplifier between the quadrature demodu- 
lator and analog to digital converter. I didn’t see 
the purpose at first, but now I know the goal of 
the Op Amp is to increase the signal power. For 
example, if the input impedance of the OpAmp 
is 100kOhm, and the output impedance is 50 
Ohm, and the voltage gain is set to 1x (or 0dB), 
there is actually a power gain of 33dB due to 
the impedance transformation through the volt- 
age follower. 

Overall, the receiver into the computer has a 
computed Noise Figure of 6dB and has sensitivity 
down to -110dBm, while consuming less than one 
Watt. 

For the transmitter, the output of the Dig- 


ital to Analog converter is 1 mA into a 400 
Ohm resistor, or around -4dBm. There is an 
LC based lumped element filter followed by an 
OpAmp that conditions the signal leading into 
the transceiver chip. The image-reject up con- 
verter has a characteristic impedance of 200 
Ohms, and on the way out a 4:1 balun is used 
to match the signal back to 50 Ohms at -10dBm. 
The signal attenuates 5dB as it goes through the 
bandpass filter bank. Next, two amplifier gain 
stages are applied to raise the signal up 15 and 
then 20 dB, resulting in a final signal strength of 
20dBm, or 100mW at the antenna jack. 


3 Software 


3.1 User Interface 


The user interface is your smartphone or tablet. 
My original dream was to have the smartphone 
interface be inside of the device, but it doesn’t 
make sense yet to integrate it all. Step by step 
we can get there, but it’s too complex for Charlie. 
Your device can be plugged into the USB OTG 
port and charged with the on-board 5V regula- 
tor, so they are good companions. 

Android/iOS can be interfaced via USB OTG 
or WiFi/Bluetooth if you attach the right add-on 
to the Whitebox. Since I’ve started this project, 
a number of high quality Applications have been 
ported and implemented. AprsDroid [6] is a 
nice interface to APRS. Sound card support is 
available today, but the Bluetooth TNC or TCP 
modes should be possible to interface with di- 
rectly given some hacking. 

FLDigi [7] was ported recently and can be sup- 
ported out of the box. This adds a lot of modes 
including MFSK, BPSK, PSK, OLIVIA, THOR, 
DOMINOEX, and MT63. All of these modes are 
supported at various standard baud rates. 

There’s no reason to not see the rest of the pop- 
ular digital modes, like JT65 [8] ported. There’s 
hope of getting FreeDV [9] and other digital voice 
modes via the Digital Voice Server [10]. I would 
really like to see CHIRP [11] ported to Android 


with some kind of universal USB programmer. 
Whitebox support would be neat, too. 

There’s lots of fun projects for smartphones, 
and when we do end up with the touch screen 
inside of a Whitebox, all of it will work natively. 
So if these kinds of projects interest you, go for 
it! 


3.2 Internal Software Stack 


From the top of the software stack, the device 
looks like a web server over a network connection. 
Bruce K6BP has been contributing to the project 
with the Algoram websocket server (checked into 
the main codebase[12]._ He ported websockets 
and cJSON to the embedded platform. There’s a 
full responsive UI for controlling the transceiver, 
as well as a web service API. The JavaScript sup- 
ports the WebAudio API and you can control 
the transceiver right from Chrome on Android 
devices. 

Available options for the receiver include a 
checkbox to turn on/off the LNA; 0dB - 48dB of 
attenuation in 6dB increments; a button to run 
the receiver calibration. The transmitter is sup- 
ported with a checkbox to turn on/off the Power 
Amplifier, and a button to run the transmitter 
calibration. Both transmit and receive can select 
the appropriate bandpass filter. There are visual 
indicators for the transceiver temperature, input 
voltage, received RSSI, and PLL lock status. 

The transceiver is controlled by the white- 
box library. This provides the verbs and nouns 
needed to control the transceiver. Things like 
‘whitebox_tx’ starts a transmission, and ‘white- 
box_write’ writes data out to the transmitter. 
Conversely, ‘whitebox_rx’ starts a receive, and 
‘whitebox_read’ reads data out of the receiver. 
There’s also data structures and methods to con- 
trol modems exposed from the FPGA. 

Linux is the common denominator of the in- 
ternal Whitebox software stack, and it provides 
a plethora of features. We even get the AX.25 
stack for free, built right into the OS. 

The kernel interfaces with all of the hardware 
via drivers, including a custom driver that con- 
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trols the digital signal processing which happens 
in the FPGA, which will be discussed at the end. 


The driver is zero memory copy, utilizing 
mmap to share memory between user space and 
the driver. A circular buffer is used to transport 
data between memory to peripherals, peripher- 
als to memory, and memory to memory with the 
Direct Memory Access Controller (DMA). 


For connectivity, as mentioned earlier, both 
USB OTG and 10/100 Ethernet are available. 
USB OTG is probably the most interesting for 
expanding the Whitebox. I ported ALSA to the 
device, and USB sound cards work great in USB 
host mode. So does WiFi, Bluetooth, and GPS 
USB dongles. 


Linux also includes a Gadget driver interface, 
and you can expose the Whitebox to your PC 
as a full USB peripheral. The same cable can 
support a sound card, a command line shell, a 
networking interface, and many more; all at the 
same time. 


I find the Ethernet to be invaluable while I 
develop. You can mount your laptop over NFS to 
do quick and iterative development. You can also 
flash the operating system over Ethernet. The 
FPGA & bootloader can be programmed from 
the Ethernet too, though I have not finalized the 
utility for this yet. 


A bricked device can be recovered via a JTAG 
header, though you do need a custom program- 
mer for now. BusPirate support is coming, but it 
depends on Actel targeting the SVF file format 
for the SmartFusion2... they say it is “Coming 
Soon”. 


The FPGA toolchain is free, if you sign up with 
Microsemi. It supports a big enough FPGA to 
have a few transceivers in one. It (apparently) 
works on RHEL Linux, though I usually use it 
on Windows. You won't have to mess with that 
stuff though unless you want to play with the 
digital signal processing chain. 
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4 Firmware 


Since the Whitebox is a quadrature transceiver 
SDR, an important process that happens in the 
baseband modem is to convert from software 
data, like audio or binary payloads, to a base- 
band signal. The baseband signal is a quadra- 
ture signal, meant to be sent through a quadra- 
ture modulator or captured from a quadrature 
demodulator. 

To transform between the software and base- 
band signals, we need a modem. This modem 
sits in the FPGA and consists of two main parts: 
the digital signal converter, and the modula- 
tors/demodulators. All of them are digital signal 
processing flowgraphs. 

The digital signal converter moves from a low 
sample rate baseband signal, to a high sam- 
ple rate baseband signal. The signal is rate- 
converted with a CIC filter, and then passes 
through a quadrature mixer for fine tuning. The 
quadrature mixer is based on complex multiplies 
instead of CORDIC, since hardware multipliers 
are plentiful on the SmartFusion2. A final FIR 
rate converter shapes the signal up to LOMSPS. 
The FIR’s coefficients are software controllable. 
The reverse flow happens on a receive. 

The modem consists of both a modulator for 
the transmitter, and a demodulator for the re- 
ceiver. I’ve sketched out a modem for AM, FM, 
SSB, and FSK, but I have not finalized the de- 
sign. The full modem will sit in the smallest Mi- 
crosemi FGPA with the digital signal converter 
by intelligently sharing the hardwired multiplier 
resources. 

I gave the Sunday Seminar at the TAPR DCC 
2014 on the concept of System on a Chip Field 
Programmable Gate Arrays. If you want to cover 
the basics, I recommend you check out the four 
hours of footage up on YouTube. 

Since the FPGA is firmware, and it can be re- 
programmed in the field, it’s important to have 
the right tools to help build the machinery in 
the FPGA. I have spent a lot of energy on using 
completely free and open tools to do all of the 
design validation. 


The flow previously has been to use Python to 
describe the register transfer logic using a sub- 
set of the language and the MyHDL library{13]. 
This has turned out to be really valuable, as it 
makes generating complex Verilog modules much 
more streamlined. You can use object oriented 
constructs in Python to help efficiently describe 
the design. 


The easiest way to do simulations is to co- 
simulate between Python and an Open Source 
verilog simulator, like Icarus Verilog|14]. This 
works pretty well, but it is not efficient at all. 
As the modem gets more complex, the simula- 
tion times grow, and it gets harder and harder 
to properly design the modem. 


I am now using an additional tool - 
Verilator{15].  Verilator takes the final Verilog 
code, and converts it into a C++ class. Oper- 
ating at the bare metal has given me a full 100x 
improvement in speed. Its not an Apples to Ap- 
ples comparison, but at the end of the day us- 
ing the new tool flow you can much more quickly 
and iteratively design new signal processing flow- 
graphs in the FPGA. 


5 Conclusion 


The problem of building a completely self- 
contained, portable software defined radio has 
been explored. The evolution of the hardware 
was documented over the three years of develop- 
ment. The details of the hardware for the most 
recent prototype were presented. The user inter- 
face and developer software stacks were covered. 
Finally, the digital signal processing firmware op- 
timizations were discussed. 


There are many sub-problems to explore as 
the hardware, software, and firmware continue 
to evolve and mature into a state that we all can 
use in the field. If you’re interested in helping 
out in any way, contact me, visit my website|16], 
and get involved! 
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GPIO pins 
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Abstract—The SatNOGS, or Satellite Network Open 
Ground Stations, project promotes and supports free and 
open space applications. It seeks to solve the problem 
of connecting many satellite users/observers to many 
ground station operators. Modern open software, web, 
and hardware techniques are used in implementing the 
Network, Database, Client, and Ground Station sub- 
projects. Modularity in all the systems promotes the 
dual-use of ground stations by not interfering with local 
operation while utilizing the great amount of time a 
civilian, non-commercial ground station would otherwise 
sit idle. 

Index Terms—SatNOGS, CubeSat, software-defined 
radio, satellite ground station, open source 


I. INTRODUCTION 


The SatNOGS [1] project seeks to build a full 
stack of open technologies for satellite ground 
stations. Civilian satellite launches have been in 
a state of change in recent years from the in- 
troduction of very small spacecraft which use 
standardized launch carriers such as the CubeSat 
and PPOD specifications [2]. This has lowered 
the bar to satellite ownership and their availability 
for educational and amateur projects and citizen 
science. 

Figure | shows that the number of CubeSat-class 
satellite launches has increased nearly exponen- 
tially since the first in 2000. Previously the domain 
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of University projects, the last 3 years have seen 
a huge increase in non-government or university 
launches. These civilian satellites include commer- 
cial, like Planet Labs’ Flock-1 satellites [3], non- 
profit, like The Planetary Society’s recent LightSail 
[4], and amateur, like AMSAT-NA’s upcoming 
Fox-1 series [5]. 


CubeSats by Mission Type (2000-present) 
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Fig. 1. CubeSat launches per year through 2015-07-17, from 
[6]. The “Commercial” category includes non-profit and amateur 
satellites. 


Each satellite owner typically operates their own 
ground station for command and control. The low- 


earth orbits (LEO) of these spacecraft result in 
short time windows when the spacecraft is above 
the local horizon for communication. As a result, 
owners seek to enlist the help of other suitably 
equipped stations for collection of data. The FUN- 
cube project is a prime example of a well-organized 
effort to receive and collect data from satellite for 
educational outreach [7]. 

Recent advances in low-cost, software-defined 
radio (SDR) technology and 3D printing have 
put ground station ownership within the reach of 
individuals. Largely composed of Amateur Radio 
operators, these people receive telemetry and data 
from many satellites and provide the information 
to the owners and the general public. 

Once an individual or organization builds a 
ground station, especially if not a commercial 
venture, the hardware ends up sitting idle for a 
great majority of the time. This capability, when 
not being actively used by the local owner, could 
be utilized for reception of other satellites. The 
SETI @home project is one of the earliest and well- 
known projects to make use of idle resources — 
compute cycles in that case [8]. 

What is missing is a civilian infrastructure to 
connect these many owners and ground station 
operators in a way that is flexible and open. The 
ESA’s Global Educational Network for Satellite 
Operations (GENSO) [9] was a notable attempt at 
such a network aimed at University-class projects 
and stations. The fact that the genso. org domain 
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Fig. 2. Overall view of the SatNOGS concept. 


name does not resolve to a live server is a practical 
indication of the current state of the project. 


Members of Hackerspace.gr [10] in Athens 
Greece first proposed SatNOGS as a part of the 
2014 International Space Apps Challenge’s “Vir- 
tual Ground Station App — Global Crowdsourcing 
of CubeSats” Challenge [11]. It was later submitted 
as an entry to the 2014 Hackaday Prize, ultimately 
winning the grand prize of $196,418 [12]. The 
funds provided seed money to start the Libre Space 
Foundation [13], a new non-profit dedicated to 
supporting free and open source space and related 
projects. 


A timely and unique aspect of the project is 
its bridging of the Maker / Hacker and the Ama- 
teur Radio communities. The 2015 TAPR/AMSAT 
Banquet’s speaker, Michael Ossmann ADONR 
pointed out the many characteristics valued and 
shared by these two communities [14]. Ward Silver, 
N@AX’s article for Makezine also does a good job 
of drawing these connections [15]. 


This paper seeks to give an overview of the 
SatNOGS project’s major components. Figure 2 
gives a high-level overview of the relationship 
between users and ground stations. Figure 3 and 
the following sections describe the four major sub- 
projects: Network, DB, Client, and Ground Station. 
The modular approach maximizes use of already 
available components at a ground station. 


GS SatN@GS SatN@GS 
RK DB NT 
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Fig. 3. The four sub-projects are designed with a modular approach 
with well-defined interfaces, allowing the ability to relatively easily 
interface with existing ground stations. 
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All code and hardware designs for the project 
are publicly available under Open Software (AG- 
PLv3 and GPLv3) and Open Hardware (CERN 
OHLv1.2) licenses [16]. Software documentation 
may be found at [17]. Note, screen captures of the 
various software components, hardware pictures, 
and demonstrations are included in the more ap- 
propriate format of the presentation instead of in 
the paper. 


Il. NETWORK 


The SatNOGS Network is accessed by users via 
a web interface. The user provides details about 
observation that they would like to schedule (which 
satellite, which band, time-frame, signal encoding, 
etc.). From this information, the system calculates 
the possible observation windows from the cur- 
rently available Ground Stations connected to the 
Network having the necessary capabilities. Once 
the observer confirms the proposed “Observation 
Job” then it is sent as a job to each Ground 
Stations’ job queue to be executed. Figure 4 shows 
this process as a diagram. 


Fig. 4. Diagram of a user scheduling an observation on the network. 


Ground Stations collect observation data then 
send it back to the Network. Uploaded data is 
then made available to the initiating user and any 
other third party via the observation’s ID. Modern 
web technologies are used on the Network website 
to provide timeline and recording visualization 
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and playback directly in the browser. Download 
links are also provided for further offline analysis. 
No special software or installation is necessary 
for users to interact with the Network. SatNOGS 
Network provides an API to allow other applica- 
tions and services to query information and, in the 
future, automatically schedule observations. 

Calculation of candidate times when the target 
satellite is visible from an active ground station 
is performed with the assistance of the PyEphem 
library [18]. The library accepts orbital elements 
for the satellite, Ground Station locations, and 
the desired time frame. With higher densities of 
Ground Stations which can see multiple satellites, 
this scheduling can be optimized for many factors. 

Because all code and documentation of all parts 
of the project are free and publicly available, 
anyone is able to contribute to these improve- 
ments. Indeed, this open collaboration is one of 
the SatNOGS project’s founding principles. 


III. DATABASE 


The coordination and aggregation provided by 
the Network component requires a centralized 
source of satellite information such as frequencies 
and transmission modes. SatNOGS DB was created 
to address the fact that there was no known public 
source for this information. In the same spirit of 
the rest of the project, the database is open access 
and not specific only to the SatNOGS project. 

Specifically, DB is a crowd-sourced suggestions 
app for transponder data. Satellites are identified 
by their NORAD (now USSPACECOM) space 
object catalog number and their common name. 
Each object has an associated set of transponder 
records which indicate frequencies and modulation 
formats. SatNOGS Network pulls this information 
when calculating possible observations. 

Updates are accepted from the public and from 
other sources of satellite information with open 
APIs. As with the Network, user interaction is 
purely web-based and requires no additional soft- 
ware besides a capable browser. 


IV. CLIENT 


SatNOGS Client consists of software running a 
computer which controls the ground station hard- 
ware. Figure 5 diagrams the internal (modular!) 


components of the client’s interaction with the 
Network. 
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Fig. 5. Client software components and interactions. 


The poller regularly checks the Network API for 
observation jobs scheduled for the local Ground 
Station. Information contained in each job includes 
satellite orbital elements, receiver tuning and de- 
modulation parameters, and timing. The PyEphem 
[18] library is used to calculate the necessary 
antenna pointing and relative velocity for doppler 
shift calculation during the pass. 

Where possible, existing standard interfaces are 
used within the Client. These include using the 
daemons rotct1 for rotator control and rigct1 
for frequency control from HamLib [19]. Any rota- 
tor controller which works with rot ct 1 automati- 
cally works with the SatNOGS Client by providing 
the appropriate IP address and port number the 
rotator is listening on. 

External programs for starting the receiver driver 
are spawned before a scheduled observation and 
setup to listen for rot ct 1 commands for doppler 
frequency corrections throughout a pass. For use 
with the popular Realtek RTL2832U DVB-T don- 
gles, the SatNOGS group maintains a version of 
rtl-sdr [20] software’s rt1_fm utility which 
accepts frequency control via rigct 1 commands 


over a network port [21]. Code for interfacing the 
Client with other SDR software is in progress, 
including receivers using GNU Radio [22]. Radios 
whose baseband signals enter the computer via 
soundcard are also planned. 

At the end of a pass, demodulated signal data is 
placed in a queue for later upload to the Network. 
Logs and other reports are also sent back to the 
Network by other API actions. 


V. GROUND STATION 


The SatNOGS Ground Station sub-project en- 
compasses the antennas, rotator, and RF path. 
Ground station owners execute the Client software 
and build or configure the hardware. Plans and 
instructions are available for the v2 ground station 
and are being finalized for the updated v3 version. 
Gears and other parts are 3D printed and the rest 
of the hardware for the ground station is easily 
available. Besides access to a 3D printer, only hand 
tools are required for building either version. 

Because the Ground Station rotator’s controller 
implements the common EasyComm 2 protocol, 
it acts like any other homebrew or commercial 
rotator controller using the same format. The Client 
software therefore works exactly the same with 
the SatNOGS rotator design or with an existing 
station’s rotator. 

There are designs for every component neces- 
sary for a SatNOGS-compatible ground station as 
part of the project. Antennas and RF path hardware 
may be use SatNOGS, homebrew, or commercial 
as the station owner deems appropriate. To help 
the goal of easily constructed ground stations, the 
project’s designs focus on common hardware, 3D- 
printed parts, and tools available in most experi- 
menters’ shops of local “maker spaces.” 


VI. CONCLUSION 


The SatNOGS project aims to provide and pro- 
mote free and open source satellite ground stations. 
Modern open software and web technologies are 
used to coordinate these stations to more fully 
utilize the reception capabilities for low earth or- 
biting satellites. By using a modular approach to 
the ground station segment, the existing stations 
of radio amateurs and others may be used with 
the network. Avoiding custom, network-specific 
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software and hardware and ensuring all design 
nformation, code, and received data is and remains 
reely available is a core tenet of the project. 
ndividuals and organizations are encouraged to 
yartner with the project to help realize these goals. 
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